Black Friday, 10:12 Uhr: Die E-Commerce-Seite zeigt einen Spinner an. MySQL-CPU steigt auf 98 %, PHP-FPM wartet. Letzte Veröffentlichung: vor fünf Tagen. Das Team bestellt ein VPS-Upgrade. Um 11 Uhr führt ein Entwickler „EXPLAIN“ für die Checkout-Anfrage aus – Typ: ALLE, Zeilen: 2.400.000. Fehlender Index für „(status, erstellt_at)“ seit dem Hinzufügen des Filters „Ausstehende Bestellungen“.
Ein fehlender Zeigefinger schreit nicht. Es baut sich auf bis zu dem Tag, an dem die Lautstärke oder der Verkehr es hörbar macht. Die gute Nachricht: Die Signatur ist im langsamen Protokoll und im EXPLAIN lesbar – wenn Sie wissen, worauf Sie vor dem Kauf von Ausrüstung achten müssen.
Signaturen einer toxischen Anfrage
In EXPLAIN signalisiert „Typ: ALL“ einen vollständigen Tabellenscan. Eine große „Zeilen“-Anzahl im Vergleich zum Ergebnis weist auf eine schlechte Selektivität oder einen fehlenden Index hin. „Filesort verwenden“ und „Temporär verwenden“ sind bei ORDER BY und GROUP BY teuer. Wiederholte Sperren signalisieren sekundäres Zurückhalten.
Langsames Abfrageprotokoll aktivieren:
slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 1
Wenn rows_examined / rows_sent > 1000 auf einer HTTP-Route ist, haben Sie einen Prioritätskandidaten.
Von der langsamen Abfrage zum nützlichen Index
Vereinfachtes Beispiel:
„sql
- AUS Bestellungen AUSWÄHLEN
WO Status = 'ausstehend' UND erstellt_at > '01.01.2026' ORDER BYcreated_at DESC LIMIT 50;
Ohne Index: Scan von Millionen Zeilen. Angepasster zusammengesetzter Index:
„sql
CREATE INDEX idx_orders_status_created ON Aufträge (Status, erstellt_at);
Reihenfolge der Spalten: Krawatten zuerst (status =), Bereiche zweitens (created_at >), ORDER BY-kompatibel, wenn möglich für einen umfassenden Scan.
Tools: langsames Protokoll mit „mysqldumpslow“, Leistungsschema, APM-Korrelationsroute und -Abfrage. Reproduzieren Sie mit nahezu Produktionsdaten – leeres Staging.
Wann nicht indexiert werden soll
Bei einer Tabelle mit einigen tausend Zeilen bleibt der Scan schnell. Eine quasi-eindeutige Spalte, die bereits über einen Primärschlüssel verfügt, benötigt kein Duplikat. Bei massiven Schreibvorgängen kostet jeder Index. Eine seltene Administratoranfrage bevorzugt Caching oder Denormalisierung.
Auf gemeinsam genutzten Systemen ist das langsame Protokoll manchmal nicht zugänglich – Symptom „Prozessorlimit erreicht“ ohne Details. Passen Sie auf VPS „innodb_buffer_pool_size“ nach den Indizes an, nicht vorher.
Oben: Die Hardware verbirgt die Abfrage
Fordern Sie vor jedem Host-Upgrade für eine „langsame Site“ die drei langsamsten Anfragen der letzten sieben Tage an. Oft ist ein zehnminütiges „CREATE INDEX“ hundert Euro VPS wert. Siehe Pool-Verbindungen und EXPLAIN PostgreSQL für das Postgres-Äquivalent.
Entscheide dich und gehe ohne blinden Fleck voran
Aktivieren Sie die langsame Protokollierung in der Produktion mit einem Schwellenwert von einer Sekunde und sammeln Sie eine Woche lang Daten, bevor Sie eine Hardware-Entscheidung treffen. Führen Sie EXPLAIN für die fünf kritischen Routenabfragen aus – Checkout, Search, Admin. Erstellen Sie einen zusammengesetzten Index und messen Sie Vorher und Nachher bei realistischer Belastung. Planen Sie nach großen Datenimporten eine vierteljährliche Überprüfung. Konfigurieren Sie über APM eine Warnung für rows_examined, um Abweichungen vor dem nächsten Handelsspitzenwert zu erkennen.
Häufig gestellte Fragen
Wie erkennt man einen fehlenden Index?
Aktivieren Sie das langsame Abfrageprotokoll und sortieren Sie nach untersuchten Zeilen. EXPLAIN zeigt den Typ ALL oder einen nicht sehr selektiven Index an – hohe Abfragezeit, wobei rows_examined viel länger ist als rows_sent.
Sollten alle WHERE-Spalten indiziert werden?
Nein. Erstellen Sie zusammengesetzte Indizes in der Reihenfolge der selektivsten Filter. Zu viele Indizes verlangsamen INSERT und UPDATE.
Kann ein Index unbrauchbar werden?
Ja – Tabellenwachstum, Abfrageänderung oder redundanter Index über linkes Präfix. Überarbeitung nach größerem Import oder Neugestaltung der Suche.
Reicht die Erhöhung des Arbeitsspeichers aus?
Vorübergehend. Ein vollständiger Scan wächst mit den Daten – der Pufferpool verbirgt den Scan einmal, nicht die strukturelle Ursache.
Die Site scheitert nicht ohne Grund – sie stößt häufig auf eine Abfrage, die EXPLAIN in einer Zeile bestätigen kann.