Deine Datenbank-Abfrage dauert plötzlich Sekunden statt Millisekunden? In den allermeisten Fällen liegt das an fehlenden oder falschen Indizes. Ein gut gesetzter Index kann eine Abfrage um das Tausendfache beschleunigen – ein falsch gesetzter kann das Schreiben verlangsamen und Speicher verschwenden. Indizes sind das vielleicht wichtigste Werkzeug zur Datenbank-Optimierung, und doch werden sie oft missverstanden. Dieser Artikel erklärt, was Indizes wirklich tun und wie du sie richtig einsetzt.
Das Telefonbuch-Prinzip
Stell dir eine Tabelle mit einer Million Kunden vor. Du suchst den Kunden mit der E-Mail-Adresse [email protected]. Ohne Index muss die Datenbank jede einzelne Zeile von oben nach unten durchgehen und vergleichen – im schlimmsten Fall alle eine Million. Das nennt man einen Full Table Scan (vollständigen Tabellendurchlauf), und er ist langsam.
Ein Index funktioniert wie das Register hinten in einem Fachbuch oder wie ein Telefonbuch: Statt jede Seite zu lesen, schlägst du gezielt nach. Weil die Einträge sortiert sind, findest du den gesuchten Eintrag in wenigen Schritten. Genau das macht ein Datenbank-Index: Er hält eine sortierte Kopie bestimmter Spaltenwerte vor, zusammen mit Verweisen auf die zugehörigen Zeilen.
Wie ein Index technisch funktioniert: Der B-Baum
Die meisten Datenbank-Indizes basieren auf einer Datenstruktur namens B-Baum (genauer: B+-Baum). Du kannst dir das wie eine mehrstufige Hierarchie vorstellen: An der Spitze steht ein Knoten, der grob in Bereiche aufteilt ("Werte A–F hier entlang, G–M dort"). Jede Ebene verfeinert die Suche, bis du am Ziel bist.
Der entscheidende Vorteil: Die Anzahl der Schritte wächst nur logarithmisch mit der Datenmenge. Verdoppelst du die Zeilenzahl, kommt nur ungefähr ein einziger zusätzlicher Suchschritt hinzu. Deshalb bleibt eine indizierte Suche auch bei Millionen Zeilen extrem schnell, während ein Full Table Scan linear langsamer wird.
Neben B-Bäumen gibt es weitere Index-Typen für Spezialfälle: Hash-Indizes für exakte Gleichheitsabfragen, Volltextindizes für die Suche in Texten und räumliche Indizes für Geodaten. Der B-Baum ist aber der universelle Standard.
Einen Index anlegen
Das Anlegen eines Index ist ein einziger SQL-Befehl:
CREATE INDEX idx_kunden_email ON kunden (email);
Das erstellt einen Index auf der Spalte email der Tabelle kunden. Ab jetzt nutzt die Datenbank diesen Index automatisch, wann immer du nach E-Mail filterst oder sortierst. Du musst in deinen Abfragen nichts ändern – die Datenbank entscheidet selbst, ob der Index sich lohnt.
Einen besonderen Index erstellst du mit CREATE UNIQUE INDEX. Er beschleunigt nicht nur die Suche, sondern stellt zusätzlich sicher, dass keine zwei Zeilen denselben Wert haben – ideal für E-Mail-Adressen oder Benutzernamen.
Welche Spalten solltest du indizieren?
Indizes sind kein Gratis-Mittagessen. Jeder Index kostet Speicherplatz und verlangsamt das Schreiben (dazu gleich mehr). Du solltest deshalb gezielt indizieren. Gute Kandidaten sind Spalten, die häufig vorkommen in:
- WHERE-Klauseln: Spalten, nach denen du oft filterst (z. B.
status,kategorie,email). - JOIN-Bedingungen: Fremdschlüssel, über die du Tabellen verknüpfst.
- ORDER BY: Spalten, nach denen du regelmäßig sortierst.
- Eindeutigkeitsprüfungen: Spalten mit eindeutigen Werten.
Der Primärschlüssel einer Tabelle ist übrigens fast immer automatisch indiziert – darum musst du dich nicht kümmern.
Zusammengesetzte Indizes und die Reihenfolge
Du kannst einen Index über mehrere Spalten anlegen – einen zusammengesetzten (composite) Index:
CREATE INDEX idx_kunden_stadt_umsatz ON kunden (stadt, umsatz);
Hier ist die Reihenfolge der Spalten entscheidend. Ein solcher Index funktioniert wie ein Telefonbuch, das erst nach Stadt und dann nach Umsatz sortiert ist. Er hilft bei Abfragen, die nach stadt allein oder nach stadt und umsatz filtern. Er hilft aber nicht, wenn du nur nach umsatz filterst – genauso wenig, wie dir ein nach Nachnamen sortiertes Telefonbuch hilft, wenn du nur den Vornamen kennst. Diese "Linksregel" (Leftmost Prefix Rule) ist eine der häufigsten Stolperfallen.
Der versteckte Preis: Indizes verlangsamen Schreibvorgänge
Hier kommt der wichtigste Punkt, den viele übersehen: Ein Index beschleunigt zwar das Lesen, aber er verlangsamt das Schreiben. Jedes Mal, wenn du eine Zeile einfügst, änderst oder löschst, muss die Datenbank nicht nur die Tabelle, sondern auch jeden betroffenen Index aktualisieren. Bei einer Tabelle mit zehn Indizes bedeutet ein einziges INSERT also elf Schreibaktionen.
Das führt zu einer wichtigen Faustregel:
- Lese-lastige Tabellen (viel SELECT, wenig Änderung) profitieren stark von Indizes.
- Schreib-lastige Tabellen (z. B. Log-Tabellen mit Millionen INSERTs) sollten nur sparsam indiziert werden.
Lege also nicht reflexartig auf jede Spalte einen Index. Mehr Indizes sind nicht automatisch besser – sie kosten Speicher und Schreib-Performance.
So findest du langsame Abfragen: EXPLAIN
Wie weißt du, ob ein Index überhaupt genutzt wird? Mit dem Befehl EXPLAIN (in manchen Systemen EXPLAIN ANALYZE oder EXPLAIN QUERY PLAN). Du stellst ihn deiner Abfrage voran:
EXPLAIN SELECT * FROM kunden WHERE email = '[email protected]';
Die Datenbank zeigt dir dann ihren Ausführungsplan: Welche Tabellen werden in welcher Reihenfolge gelesen, welche Indizes genutzt, und wie viele Zeilen werden voraussichtlich durchsucht. Siehst du dort einen "Full Table Scan" oder "Sequential Scan" über eine große Tabelle, ist das ein deutliches Signal, dass ein Index fehlt. Tauchen die Stichworte "Index Scan" oder "Index Seek" auf, arbeitet dein Index wie gewünscht.
Häufige Fehler, die Indizes wirkungslos machen
Manchmal ist ein Index vorhanden, wird aber trotzdem nicht genutzt. Typische Ursachen:
- Funktionen auf der indizierten Spalte:
WHERE LOWER(email) = '[email protected]'umgeht den normalen Index, weil die Datenbank den Wert erst berechnen muss. Abhilfe schafft ein Funktions- oder Ausdrucksindex. - Führende Platzhalter bei LIKE:
WHERE name LIKE '%mann'kann keinen B-Baum-Index nutzen, weil der Anfang unbekannt ist.WHERE name LIKE 'Mann%'hingegen schon. - Datentyp-Mismatch: Vergleichst du eine Zahlenspalte mit einem Text (
WHERE id = '42'), kann der Index ignoriert werden. - Geringe Selektivität: Ein Index auf einer Spalte mit nur zwei möglichen Werten (etwa
aktiv= ja/nein) bringt wenig, weil er die Treffermenge kaum eingrenzt.
Indizes pflegen
Über die Zeit können Indizes "fragmentieren" – besonders bei vielen Lösch- und Einfügeoperationen. Die meisten Datenbanken pflegen ihre Indizes weitgehend selbst, aber gelegentliches Reorganisieren (z. B. REINDEX in SQLite/PostgreSQL oder OPTIMIZE TABLE in MySQL) kann die Performance auffrischen. Außerdem solltest du ungenutzte Indizes aufspüren und entfernen – sie kosten nur, ohne zu nützen.
Praxis-Checkliste für gute Indizes
- Finde deine langsamen Abfragen (Slow-Query-Log oder Monitoring).
- Analysiere sie mit EXPLAIN.
- Indiziere Spalten in WHERE-, JOIN- und ORDER-BY-Klauseln.
- Achte bei zusammengesetzten Indizes auf die richtige Spaltenreihenfolge.
- Vermeide übermäßig viele Indizes auf schreib-lastigen Tabellen.
- Miss vorher und nachher – verlasse dich nicht auf Bauchgefühl.
Wenn du beim Optimieren regelmäßig Zahlen, Größen oder Zeiten berechnest, helfen dir die Webtools von kotsch.tech mit passenden Rechnern. Und wer das Fundament noch festigen will, sollte zuerst die SQL-Grundlagen sicher beherrschen.
Häufige Fragen
Wie viele Indizes sind zu viele?
Es gibt keine feste Zahl. Als Orientierung: Auf schreib-lastigen Tabellen sind wenige, gut gewählte Indizes besser. Wichtiger als die Anzahl ist, dass jeder Index tatsächlich von Abfragen genutzt wird. Ungenutzte Indizes solltest du löschen.
Beschleunigt ein Index auch Sortierungen?
Ja. Wenn du nach einer indizierten Spalte sortierst (ORDER BY), kann die Datenbank die bereits sortierte Index-Struktur nutzen und sich den separaten Sortierschritt sparen.
Muss ich Indizes manuell aktualisieren?
Nein. Die Datenbank aktualisiert Indizes automatisch bei jedem INSERT, UPDATE und DELETE. Du musst dich nur um das Anlegen und gelegentliche Aufräumen kümmern.
Warum ignoriert die Datenbank manchmal meinen Index?
Häufige Gründe sind Funktionen auf der Spalte, führende LIKE-Platzhalter, Datentyp-Konflikte oder geringe Selektivität. Manchmal entscheidet der Abfrageoptimierer auch bewusst, dass ein Full Table Scan bei kleinen Tabellen schneller ist. EXPLAIN zeigt dir, was wirklich passiert.