Datenbank-Index erklärt:das Telefonbuch für deine App

Datenbank-Index erklärt: Jeder Index funktioniert genau wie ein Telefonbuch – statt jede Seite zu lesen, um einen Namen zu finden, springst du direkt dorthin. Ohne Index liest deine Datenbank jede einzelne Zeile einer Tabelle, um eine Frage zu beantworten. Mit einem fiel eine echte Abfrage auf denselben Daten von 2.300 Millisekunden auf 2,3 – tausendmal schneller –, weil sie 47 passende Zeilen statt 500.000 durchsuchte.

Indizes sind das wirksamste Performance-Werkzeug, das du je anfassen wirst, sie erfordern null Codeänderungen, und die KI vergisst routinemäßig, sie hinzuzufügen. Hier steht, was sie sind, die eine Regel, die 90 % der Fälle abdeckt, und die echten Produktionszahlen, die zeigen, worum es geht.

Datenbank-Index erklärt: was ist ein Datenbank-Index?

Überlege, wie du „Gonçalves“ in einem Telefonbuch findest. Du beginnst nicht auf Seite eins und liest jeden Eintrag – du nutzt die Tatsache, dass das Buch sortiert ist, springst in die Nähe der G's und landest in Sekunden beim Namen. Stell dir jetzt dasselbe Telefonbuch mit Einträgen in zufälliger Reihenfolge vor. Einen Namen zu finden heißt, das ganze Buch zu lesen, jedes Mal, bei jeder Suche.

Dieses zweite Telefonbuch ist eine Datenbanktabelle ohne Index. Tabellen speichern Zeilen in keiner sinnvollen Reihenfolge, sodass eine Frage wie „zeig mir die Aufgaben dieses Kunden“ die Datenbank zwingt, jede Zeile zu prüfen und die Treffer zu behalten – ein Full Scan. Ein Index ist das sortierte Telefonbuch, das die Datenbank nebenher pflegt: eine Schnellsuch-Kopie einer Spalte (oder mehrerer), mit der sie direkt zu den passenden Zeilen springen kann.

Übersetzt in Nutzererfahrung: 2,3 Sekunden ist eine Seite, bei der deine Kunden beim Laden zusehen. 2,3 Millisekunden ist sofort. Dieselbe Abfrage, dieselben Daten – der einzige Unterschied ist ein Index.

Die Regel: indiziere jeden Foreign Key

Du musst kein Performance-Ingenieur werden. Eine Regel deckt die überwältigende Mehrheit der Fälle in der Praxis ab:

Indiziere jeden Foreign Key und jede Spalte, nach der du häufig filterst oder sortierst.

Ein Foreign Key ist jede Spalte, die auf eine andere Tabelle verweist – den Kunden, zu dem eine Aufgabe gehört, das Projekt, das eine Rechnung abrechnet, den Status, den ein Datensatz trägt. In einer gut strukturierten Datenbank (so eine bekommst du durch richtiges Normalisieren) sind diese Referenzspalten überall, und genau sie nutzt die Datenbank, um Tabellen zu verbinden, wenn sie Fragen beantwortet. Jede davon bekommt einen Index. Keine Ausnahmen, keine Ermessensentscheidung.

Darüber hinaus indiziere die Spalten, nach denen deine Screens ständig filtern und sortieren: die Organisation, zu der jede Zeile gehört (das Rückgrat von mandantenfähigen Apps, bei praktisch jeder Abfrage gefiltert), Erstellungsdaten für „neueste zuerst“-Listen und den Soft-Delete-Zeitstempel, den fast jede Abfrage prüft, um gelöschte Datensätze auszublenden. Die Gewohnheit ist eine Zeile pro Spalte beim Anlegen der Tabelle – CREATE INDEX idx_tasks_project_id ON tasks(project_id); – und es ist eine Gewohnheit, die die KI nicht für dich pflegt: Generierte Schemata definieren routinemäßig die Referenzen und lassen die Indizes weg, was in einer Demo mit 50 Zeilen einwandfrei funktioniert und bei 500.000 zusammenbricht.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Zusammengesetzte Indizes: der zweite Trick des Telefonbuchs

Ein Telefonbuch ist nicht nach einer Sache sortiert – es ist nach Nachname sortiert, dann nach Vorname. So findest du jeden „Schmidt“ oder genau „Schmidt, Hans“. Was es nicht kann, ist jeden „Hans“ unabhängig vom Nachnamen zu finden – dafür musst du wieder das ganze Buch lesen.

Ein zusammengesetzter Index (Composite Index) ist dieselbe Struktur über zwei oder mehr Spalten und folgt demselben Links-nach-rechts-Gesetz. Ein Index auf (Organisation, Status) beschleunigt „alles für diese Organisation“ und „alles für diese Organisation mit diesem Status“ – bringt aber nichts für „alles mit diesem Status über alle Organisationen hinweg“, denn der Status ist der Vorname, nicht der Nachname.

Die praktische Konsequenz: Die Reihenfolge der Spalten zählt. Setze die Spalte nach vorn, nach der du immer filterst – in einem mandantenfähigen Produkt ist das die Organisation. Und zusammengesetzte Indizes haben eine Bonuskraft: Wenn die Reihenfolge des Index zur Sortierreihenfolge deiner Abfrage passt, kommen die Ergebnisse vorsortiert heraus, und der Sortierschritt entfällt komplett.

Wann du NICHT indizieren solltest

Indizes sind nicht kostenlos: Jeder braucht Speicherplatz und muss bei jedem Schreibvorgang aktualisiert werden, sodass jeder zusätzliche Index Inserts und Updates ein wenig langsamer macht. Vier Situationen, in denen du darauf verzichten solltest:

Spalten mit zwei Werten. Ein Wahr/Falsch-Flag teilt die Tabelle etwa in der Mitte – zur „Hälfte des Buchs“ zu springen spart nichts. Kleine Tabellen. Unter etwa 1.000 Zeilen ist die ganze Tabelle praktisch sofort gelesen; der Primärschlüssel reicht. Spalten, die du nie durchsuchst. Nur Spalten, die in Filtern, Sortierungen oder Verknüpfungen vorkommen, verdienen einen Index – Freitext-Notizen nicht. Ständig wechselnde Spalten in schreiblastigen Tabellen. Jede Änderung muss auch den Index aktualisieren; bei einer Tabelle, die meist geschrieben und selten gelesen wird, geht dieser Tausch in die falsche Richtung.

Die goldene Regel: Jeder Index sollte seine Existenz mit einer messbaren Verbesserung der Abfrage rechtfertigen. Indizieren „für alle Fälle“ führt zu langsamen Schreibvorgängen und verschwendetem Speicher.

Echte Produktionszahlen

Drei echte Vorher-nachher-Messungen, jede ein gängiger Screen in einem SaaS-Produkt:

Jede Zeile erzählt dieselbe Geschichte: Die Datenbank hörte auf, alles zu lesen, und begann zu springen. Und der Ablauf, der sie hervorbrachte, ist für jeden Gründer wiederholbar: den langsamen Screen finden, die Datenbank bitten zu erklären, wie sie die Abfrage beantwortet hat (jede Datenbank hat eine „Explain“-Funktion – und die KI zu bitten, ihre Ausgabe zu interpretieren, funktioniert wunderbar), den Index anlegen, auf den die Erklärung hinweist, erneut messen. Wenn der Bericht sagt „500.000 Zeilen durchsucht, um 20 zurückzugeben“, hast du deinen fehlenden Index gefunden.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Wie finde ich die Indizes, die mir fehlen?

Folge der Langsamkeit. Wenn eine Seite hängt, nimm ihre Abfrage, führe die Explain-Funktion deiner Datenbank darauf aus und suche nach Full Table Scans – der Bericht sagt wörtlich, wie viele Zeilen gelesen und wie viele zurückgegeben wurden. Moderne Datenbank-Dashboards zeigen außerdem die langsamsten Abfragen an und schlagen oft direkt den fehlenden Index vor. Füge alles davon in die KI ein, um eine Deutung in einfachen Worten zu bekommen.

Kann ich zu viele Indizes haben?

Ja. Jeder Index belastet jeden Schreibvorgang und belegt Speicher, sodass eine Tabelle mit einem Dutzend spekulativer Indizes echte Kosten für hypothetische Abfragen zahlt. Beginne mit der Regel – Foreign Keys, Organisation, häufige Filter – und füge nur dann weitere hinzu, wenn eine gemessene langsame Abfrage es verlangt, und entferne Indizes, die nichts nutzt.

Beschleunigen Indizes auch Schreibvorgänge?

Nein – im Gegenteil, leicht. Ein Index beschleunigt das Lesen, muss aber selbst aktualisiert werden, sobald sich Daten ändern, sodass Schreibvorgänge pro Index eine kleine Gebühr zahlen. Für ein typisches SaaS-Produkt, das viel mehr liest als schreibt, lohnt sich dieser Tausch überwältigend; indiziere nur keine Spalten, die nie jemand durchsucht.

Fügt die KI Indizes automatisch für mich hinzu?

Manchmal, unregelmäßig – und fehlende Foreign-Key-Indizes sind eine der häufigsten Lücken in KI-generierten Schemata, weil die Demo auch ohne sie gut läuft. Mach es explizit: Sag der KI, dass jede Tabelle, die sie anlegt, ihre Foreign Keys und häufig gefilterten Spalten indizieren muss, und prüfe das Schema wie eine Checkliste gegen diese Regel.