Als Erstes müssen Sie sich darüber im Klaren sein, dass MySQL nur einen Index pro Pseudo-SELECT (keine Anweisung) verwendet. Wenn Sie die Ausgabe von SELECT mit EXPLAIN anzeigen, sehen Sie, welcher Index pro ausgewählt wurde. EXPLAIN kann nur auf SELECTS ausgeführt werden, daher müssen wir davon ausgehen, dass ein DELETE/UPDATE denselben Plan verwendet, wenn Sie die Syntax für SELECT...
austauschenDie meisten Datenbanken (eingebettete können seltsam sein) unterstützen meines Wissens die Verwendung von Indizes in den folgenden Klauseln:
- AUSWÄHLEN
- JOIN (ANSI-92-Syntax)
- WO (weil es ANSI-89 und gibt Filterung hier)
- HAVING (WHERE äquivalent, aber im Gegensatz zu WHERE - erlaubt aggregierte Verwendung ohne Unterabfrage)
- BESTELLUNG PER
Ich bin nicht zu 100 % auf GROUP BY, also lasse ich es vorerst weg.
Letztendlich ist es die Wahl des Optimierers, was basierend auf seinem Algorithmus und den verfügbaren Statistiken verwendet werden soll. Sie können die ANALYZE TABLE-Syntax verwenden um die Statistik zu aktualisieren (periodisch, bitte nicht ständig).
Nachtrag
MySQL begrenzt auch die Menge an Speicherplatz für die Zuweisung von Indizes - 1.000 Bytes für MyISAM-Tabellen und 767 Bytes für InnoDB-Tabellen . Da MySQL nur einen Index pro Pseudo-SELECT verwendet, ist das Abdecken von Indizes (Indizes, die mehr als eine Spalte enthalten) eine gute Idee, aber es geht wirklich darum, die häufigste Abfrage zu testen und so gut wie möglich dafür zu optimieren. Die Indizierungspriorität sollte sein:
- Primärschlüssel (irgendwo in v5 wurde die Indexerstellung für das pk automatisch)
- Fremdschlüssel (nächster wahrscheinlichster JOIN-Kandidat
- Filterkriterien (vorausgesetzt, Sie haben Platz)
