Eine Shop-Datenbank ohne Indizes: Jeder Filter und jeder Join wurde zum Full Scan, bis die richtigen Indizes Mikrosekunden brachten

Dass ein Index eine Abfrage beschleunigt, ist nicht der interessante Teil. Interessant ist, wann ein Index existiert und nicht hilft, und wie man den Plan liest, um das zu sehen.

„Index benutzt“ ist nicht dasselbe wie schnell

Der Plan zeigt einen Schlüsselnamen auch dann, wenn die Datenbank den ganzen Index liest. Die Spalte, die man lesen muss, ist der Zugriffstyp: ref, eq_ref und range bedeuten ein Nachschlagen über den Index, index einen vollständigen Scan des Index, ALL einen vollständigen Scan der Tabelle. Ein Plan kann einen Schlüssel nennen und Using index melden und darunter trotzdem eine Million Einträge lesen. Der Schlüsselname ist nicht der Beleg; der Zugriffstyp und die Zeilenzahl sind es.

Der Index existiert, und die Datenbank ignoriert ihn

Auf der Statusspalte, fünf verschiedene Werte, haben wir einen Index angelegt, und eine Summe der Bestellbeträge bezahlter Bestellungen lief trotzdem als vollständiger Scan der Tabelle: 500 000 Zeilen, 35,7 ms. Das ist kein Fehler des Optimierers, sondern eine Entscheidung: Bezahlte Bestellungen sind 20 Prozent der Tabelle, und der Betrag steht nicht im Index, also hieße der Index 100 000 zufällige Sprünge zu Zeilen, was mehr kostet als ein sequenzieller Scan. Ein Index auf einer Spalte mit wenigen verschiedenen Werten ändert oft nichts.

Eine Funktion auf der Spalte schaltet den Index ab

Mit einem Index auf dem Bestelldatum verhalten sich zwei Abfragen nach demselben Tag völlig verschieden. Die Bedingung mit dem Datum in einer Funktion liest den ganzen Index, 500 000 Einträge, 32,7 ms. Die Bedingung als Bereich von Mitternacht bis Mitternacht liest 556 Zeilen in 0,073 ms. Der Unterschied von etwa 447-mal kommt allein von der Funktion um die Spalte:

WHERE DATE(created_at) = '2026-06-15'                              vollständiger Index-Scan
WHERE created_at >= '2026-06-15' AND created_at < '2026-06-16'      Bereichssuche

Eine indexierte Spalte in irgendetwas zu hüllen, eine Funktion, eine Verkettung, eine Umwandlung, nimmt die Bereichssuche weg. Die Regel schreibt man auf der Seite des Werts, nicht der Spalte.

Eine implizite Typumwandlung: ein falsches Ergebnis, und langsamer

Die gefährlichste Falle, weil sie die Korrektheit trifft, nicht nur die Geschwindigkeit. Die Statusspalte ist Text. Mit dem Textwert verglichen liefert die Abfrage 100 000 Zeilen in 8,5 ms über den Index. Mit der Zahl 0 statt eines Textes verglichen liefert sie alle 500 000 Zeilen in 84,6 ms mit einem vollständigen Scan des Index. MariaDB wandelt für den Vergleich jeden Text in eine Zahl, jeder Status wird 0, und die Bedingung passt auf jede Zeile. Die Abfrage ist langsamer, liefert das falsche Ergebnis und gibt nur eine Warnung aus, die niemand liest. Die Typen in einer Bedingung müssen zusammenpassen.

Ein zusammengesetzter Index wirkt nur von links

Ein zusammengesetzter Index auf Produkt und Menge in den Positionen bedient eine Bedingung auf das Produkt in 0,020 ms. Eine Bedingung auf die Menge allein kann ihn nicht zum Nachschlagen nutzen und scannt den ganzen Index, 1,75 Millionen Einträge, 96,1 ms. Ein mehrspaltiger Index bedient Bedingungen nur von seinem linken Rand aus, also ist die Spaltenreihenfolge eine Entwurfsentscheidung, gewählt für die echten Abfragen.

Ein abdeckender Index beseitigt die Sprünge zu Zeilen

Eine Liste der tausend neuesten Bestellungen mit Nummer und Betrag: Mit einem Index auf dem Datum allein liest die Datenbank den Index in Reihenfolge, muss aber für den Betrag zu jeder Zeile springen, 0,75 ms. Mit einem Index auf Datum und Betrag steht alles, was die Abfrage braucht, im Index, keine Sprünge, 0,24 ms. Bei größeren Ergebnissen und kaltem Cache ist der Unterschied weit größer als dieses Dreifache.