Wenn Sie die maximale Abrufgeschwindigkeit wünschen und beide Spalten in den Join- oder Where-Bedingungen haben, ABER manchmal hat Spalte a eine höhere Selektivität und manchmal hat Spalte b eine höhere Selektivität, und Sie möchten diese Tatsache aus einem einzelnen Index nutzen.
Außerdem denke ich, dass Ihr Verhältnis von Datengröße / Leistung der Maschine ziemlich hoch sein sollte und Sie gleichzeitig (schätzungsweise) bereit sein müssen, jede Verbesserung als notwendig zu bezeichnen (wenn auch nur um einige Prozent).
Die Erfahrung lehrt jedoch, dass die Dinge von vielen Faktoren abhängen; mit spezifischen RDBMS und Anwendungsumgebungen führen Sie besser Ihre eigenen Benchmarks durch.
BEARBEITEN:Weitere Erläuterungen zu zusammengesetzten Indizes aus Wikipedia
:
"Die Reihenfolge, in der Spalten in der Indexdefinition aufgelistet werden, ist wichtig. Es ist möglich, einen Satz von Zeilenkennungen abzurufen, indem nur die erste indizierte Spalte verwendet wird. Es ist jedoch nicht möglich oder effizient (on die meisten Datenbanken), um den Satz von Zeilenkennungen abzurufen, indem nur die zweite oder größere indizierte Spalte verwendet wird.
Stellen Sie sich zum Beispiel ein Telefonbuch vor, das zuerst nach Stadt, dann nach Nachname und dann nach Vorname organisiert ist Wenn Sie die Stadt angegeben haben, können Sie die Liste aller Telefonnummern für diese Stadt leicht extrahieren. Es wäre jedoch sehr mühsam, in diesem Telefonbuch alle Telefonnummern für einen bestimmten Nachnamen zu finden. Sie müssten in den einzelnen Städten suchen Abschnitt für die Einträge mit diesem Nachnamen."
Die Erklärungen von Wikipedia sind vielleicht zu stark vereinfacht, aber sie geben Ihnen die Grundidee (beachten Sie bei Analogien, dass Telefonbücher normalerweise gruppierte Indizes haben und dies nicht Ihr allgemeiner Datenbankindex wäre).
Abhängig von der Größe des Index vs. Größe der Datenstruktur vs. verfügbarem Speicher vs. Selektivität in der ersten Spalte des Indexes kann es immer noch viel billiger sein, einen falsch geordneten Index zu verwenden, als Tabellenscans zu verwenden.
Ah, ich dachte nur an eine bessere Analogie mit einem Beispiel, nach dem Sie suchen. Stellen Sie sich ein schönes Lehrbuch vor, es hätte ein Inhaltsverzeichnis mit Kapiteln und Unterkapiteln und der Anzahl der Seiten, auf denen sie sich befinden (was ein nicht gruppierter Index ist, der Zeiger enthält auf Datensätze - Seiten). Stellen Sie sich nun vor, dass das Lehrbuch auf dem SQL-92-Standard basiert, dann wären die meisten Begriffe im Inhaltsverzeichnis SQL-Begriffe (halten Sie an dieser Annahme fest). Sie hätten auch einen weiteren Index am Ende des Buchs, der dies tun würde listet alle interessanten Begriffe in alphabetischer Reihenfolge (angenommen mit Hauptkapitelnamen) und Seitenzahlen auf.
Für Fragen wie „Sagen Sie mir alle Kapitel, unter denen DISTINCT erscheint“ würden Sie den zweiten Index verwenden (weil die Selektivität des späteren Felds hoch ist)
Für Fragen wie „Sagen Sie mir die Anzahl der Begriffe, die im ersten Kapitel erscheinen“ würden Sie das Inhaltsverzeichnis verwenden
Also für Fragen wie "Ist SELECT im DML-Kapitel beschrieben?" Sie könnten einen der beiden Indizes verwenden (weil die Selektivität beider Felder hoch ist). Wenn das Inhaltsverzeichnis von DML selbst jedoch 3 Seiten lang ist und der SELECT-Eintrag im Index nur fünfzehn Zeilen hat, würden Sie wahrscheinlich zum zweiten gehen, und das ist ein Beispiel dafür, wann Sie von beiden Indizes profitieren.
Nun, wenn Sie denken, dass das zu weit hergeholt ist, ziehen Sie eine Datenbank der gescannten Kongressbibliothek in Betracht. :)
Wie ich schon sagte, die ganze Planung ist in Ordnung, aber am Ende führen Sie Ihre eigenen Benchmarks durch.
