@ Pierre 303 hat es bereits gesagt, aber ich werde es noch einmal sagen. DO verwenden Indizes für Kombinationen von Spalten. Ein kombinierter Index für (a, b)ist für Abfragen nur geringfügig langsamer aals ein Index für aallein und ist erheblich besser, wenn Ihre Abfrage beide Spalten kombiniert. Einige Datenbanken können Indizes für aund bvor dem Erreichen der Tabelle verknüpfen, dies ist jedoch bei weitem nicht so gut wie ein kombinierter Index. Wenn Sie einen kombinierten Index erstellen, sollten Sie die Spalte, die am wahrscheinlichsten zuerst durchsucht wird, in den kombinierten Index einfügen.
Wenn Ihre Datenbank unterstützt, DO setzen Indizes für Funktionen , die in Abfragen statt Spalten angezeigt. (Wenn Sie eine Funktion für eine Spalte aufrufen, sind die Indizes für diese Spalte unbrauchbar.)
Wenn Sie eine Datenbank mit echten temporären Tabellen verwenden , dass Sie on the fly erstellen und zerstören (zB PostgreSQL, MySQL, aber nicht Oracle), dann DO Indizes für temporäre Tabellen erstellen.
Wenn Sie eine Datenbank verwenden , die es ermöglicht (zB Oracle), DO Sperre in guten Abfrageplänen. Abfrageoptimierer ändern im Laufe der Zeit die Abfragepläne. Sie verbessern normalerweise den Plan. Aber manchmal machen sie es dramatisch schlimmer. Im Allgemeinen werden Sie Planverbesserungen nicht wirklich bemerken - die Abfrage war kein Engpass. Ein einzelner fehlerhafter Plan kann jedoch eine geschäftige Site zum Erliegen bringen.
KEINE Indizes für Tabellen, für die Sie eine große Datenmenge laden möchten. Es ist viel, viel schneller, Indizes zu löschen, die Daten zu laden und anschließend die Indizes neu zu erstellen, als sie beim Laden der Tabelle beizubehalten.
NICHT verwenden Indizes für Abfragen , die mehr als einen kleinen Bruchteil einer großen Tisch Zugriff haben. (Wie klein das ist, hängt von der Hardware ab. 5% sind eine gute Faustregel.) Wenn Sie beispielsweise Daten mit Namen und Geschlecht haben, sind Namen ein guter Kandidat für die Indizierung, da jeder gegebene Name einen kleinen Bruchteil der gesamten Zeilen darstellt. Es wäre nicht hilfreich, nach Geschlecht zu indizieren, da Sie immer noch auf 50% der Zeilen zugreifen müssen. Sie möchten stattdessen wirklich einen vollständigen Tabellenscan verwenden. Der Grund dafür ist, dass Indizes zufällig auf eine große Datei zugreifen, sodass Sie eine Festplattensuche benötigen. Festplatten-Suchvorgänge sind langsam. Als Beispiel habe ich kürzlich eine einstündige Abfrage beschleunigt, die so aussah:
SELECT small_table.id, SUM(big_table.some_value)
FROM small_table
JOIN big_table
ON big_table.small_table_id = small_table.id
GROUP BY small_table.id
auf unter 3 Minuten durch Umschreiben wie folgt:
SELECT small_table.id, big_table_summary.summed_value
FROM small_table
JOIN (
SELECT small_table_id, SUM(some_value) as summed_value
FROM big_table
GROUP BY small_table_id
) big_table_summary
ON big_table_summary.small_table_id = small_table.id
Dies zwang die Datenbank zu verstehen, dass sie nicht versuchen sollte, den verlockenden Index für zu verwenden big_table.small_table_id. (Eine gute Datenbank wie Oracle sollte dies selbst herausfinden. Diese Abfrage wurde unter MySQL ausgeführt.)
Update: Hier ist eine Erklärung des von mir festgelegten Disk-Suchpunkts. Ein Index gibt einen schnellen Überblick darüber, wo sich die Daten in der Tabelle befinden. Dies ist normalerweise ein Gewinn, da Sie nur die Daten anzeigen, die Sie anzeigen müssen. Aber nicht immer, vor allem, wenn Sie sich irgendwann viele Daten ansehen werden. Festplatten streamen Daten gut, machen Suchvorgänge jedoch langsam. Eine zufällige Suche nach Daten auf der Festplatte dauert 1/200 Sekunde. Die langsame Version der Abfrage ergab ungefähr 600.000 Treffer und dauerte fast eine Stunde. (Es wurden mehr Suchvorgänge ausgeführt, aber einige davon wurden durch das Caching erfasst.) Im Gegensatz dazu wusste die schnelle Version, dass sie alles lesen und Daten mit einer Geschwindigkeit von etwa 70 MB / s streamen musste. Es kam durch eine 11 GB-Tabelle in weniger als 3 Minuten.