Database Indexing fuer kleine Anwendungen — Daten finden, bevor sie uns suchen

Die meisten Datenbankprobleme kommen nicht mit einem Alarm. Eine kleine Anwendung fuehlt sich am ersten Tag schnell an, die Datentabelle hat ein paar hundert Zeilen, und jede Seite scheint in Ordnung zu sein. Dann braucht ein Bericht vier Sekunden, die Admin-Suche stockt, oder ein Kunde fragt, warum eine gewoehnliche Seite ploetzlich langsam ist. Ich habe gelernt, dass die Ursache oft kein exotisches Serverproblem ist. Die Datenbank soll einfach jede Schublade in einem immer groesseren Schrank durchsuchen.

Database Indexing ist das Etikett auf diesen Schubladen. Es hilft MySQL, die benoetigten Zeilen zu finden, ohne zuerst die ganze Tabelle zu lesen. Ein Index ist keine Magie und gehoert nicht ueberall hin, aber einige bewusst gewaehlte Indizes koennen eine bescheidene Anwendung wieder ruhig wirken lassen. Dieser Artikel zeigt praktisch, wann Indizes helfen, wie man das Ergebnis prueft und wie ein nuetzliches Werkzeug nicht zum Pflegeballast wird.

Was ein Index wirklich veraendert

Stell dir vor, du suchst eine Quittung in einer Kiste mit tausenden Quittungen. Ohne Ordnung pruefst du ein Blatt nach dem anderen. Mit einem Ordner nach Monat und Lieferant gehst du direkt zu einem viel kleineren Bereich. Ein Datenbankindex funktioniert aehnlich. Er speichert ausgewaehlte Spaltenwerte in einer Struktur, die MySQL effizient durchsuchen kann, zusammen mit einem Verweis auf die passende Zeile.

Nimm eine Tabelle posts mit einer oeffentlichen Seite, die einen published Artikel anhand seines Slugs abruft. Ohne einen Index auf slug muss MySQL moeglicherweise jeden Post durchsuchen, bis der richtige Wert gefunden ist. Das nennt man full table scan. Bei fuenfzig Zeilen ist das vielleicht unauffaellig, mit wachsender Tabelle und gleichzeitigem Traffic wird es jedoch verschwenderisch. Ein Index gibt MySQL eine Abkuerzung vom angefragten Slug zur passenden Zeile.

Der wichtige Punkt ist: Ein Index bedient ein access pattern, nicht die Beliebtheit einer Spalte. Eine Spalte ist ein Kandidat, wenn sie haeufig in WHERE, JOIN, ORDER BY oder manchmal GROUP BY vorkommt. „Sie sieht wichtig aus“ ist kein ausreichender Grund. Die Query ist der Beleg.

Mit den Seiten beginnen, auf die Menschen wirklich warten

Bevor du etwas erstellst, schreibe eine kurze Liste langsamer oder stark besuchter Aktionen. In einem kleinen CMS kann das das Oeffnen eines oeffentlichen Artikels sein, das Filtern published Posts nach Kategorie, die Suche nach einer Bestellung ueber die Kunden-E-Mail oder das Laden der letzten Aktivitaet im Admin-Panel. Erfasse das SQL der Anwendung oder schreibe die Query in einen Datenbank-Client. Nur vom Tabellenschema zu raten ist wie Schluessel zu kaufen, bevor man die Tueren kennt.

Eine Artikelliste kann zum Beispiel diese Query verwenden:

SELECT id, title, slug, created_at
FROM posts
WHERE status = 'published'
  AND is_deleted = 0
ORDER BY created_at DESC
LIMIT 20;

Diese Query filtert nach status und is_deleted und sortiert dann nach created_at. Weil sie fuer jeden Besucher wiederholt wird, ist sie ein staerkerer Index-Kandidat als ein einmaliger Export. Das Ziel ist nicht, jede Query raffiniert aussehen zu lassen; das Ziel ist ein gut beleuchteter Weg fuer den oft genutzten Ablauf.

EXPLAIN vor und nach der Aenderung verwenden

MySQL kann zeigen, wie es eine Query ausfuehren will. Stelle der Anweisung EXPLAIN voran:

EXPLAIN SELECT id, title, slug, created_at
FROM posts
WHERE status = 'published'
  AND is_deleted = 0
ORDER BY created_at DESC
LIMIT 20;

Behandle die Ausgabe nicht wie eine Bewertung. Lies sie als Hinweis. Ein type-Wert ALL bedeutet oft einen full scan. Die Spalte key zeigt, welchen Index MySQL gewaehlt hat, waehrend rows seine Schaetzung der zu pruefenden Zeilen ist. Bei einer viel genutzten Query sind ein passender key und eine deutlich kleinere Zeilenschaetzung meistens ermutigend.

Teste nach Moeglichkeit mit realistischen Daten. Eine Query, die mit zwanzig Development-Records schnell ist, kann sich mit jahrelangen Bestellungen oder Logs ganz anders verhalten. Auch ein langsames Ergebnis bedeutet nicht automatisch „Index hinzufuegen“. Vielleicht fehlt ein Limit, es werden unnoetige Spalten ausgewaehlt, es gibt ein Cache-Problem oder die Form der Query sollte sich aendern.

Composite Indizes folgen der Reihenfolge der Query

Eine der nuetzlichsten Ideen ist der composite index: ein Index ueber mehr als eine Spalte. Fuer die Query der Artikelliste kann ein Index passend sein, der ihren Filtern und ihrer Sortierung folgt:

CREATE INDEX idx_posts_public_listing
ON posts (status, is_deleted, created_at DESC);

Stell ihn dir wie ein Telefonbuch vor, das zuerst nach Status, dann nach Loeschstatus und danach nach Datum gruppiert ist. MySQL kann die passende Gruppe eingrenzen und ihre neuesten Records der Reihe nach lesen. Die Spaltenreihenfolge ist wichtig. Ein Index, der mit status beginnt, ist nicht automatisch fuer eine Query nuetzlich, die nur nach created_at filtert; die linken Spalten bilden den am besten zugaenglichen Teil des Index.

Ein haeufiger Fehler ist, fuer jede Spalte einen eigenen Index hinzuzufuegen und anzunehmen, MySQL werde sie immer perfekt kombinieren. Das kann gelegentlich funktionieren, aber ein composite index, der eine wichtige Query widerspiegelt, ist oft klarer und schneller. Erstelle den kleinsten Index fuer eine gemessene workload und behalte ihn nur, wenn EXPLAIN und reale Antwortzeiten ihn rechtfertigen.

Indizes haben Kosten, also bewusst waehlen

Ein Index beschleunigt reads, indem er Speicherplatz verbraucht und writes zusaetzliche Arbeit gibt. Wenn eine Zeile eingefuegt, aktualisiert oder geloescht wird, muss MySQL moeglicherweise auch jeden relevanten Index aktualisieren. Eine Tabelle, die gelegentlich Artikel erhaelt, vertraegt einige gut durchdachte Indizes. Eine Tabelle, die jeden Request oder jedes Event aufzeichnet, kann unter einem Dutzend spekulativer Indizes leiden.

Vermeide es, Spalten mit allein nur wenigen verschiedenen Werten zu indexieren, etwa einen boolean flag, ausser die umgebende Query und die Tabellengroesse beweisen den Nutzen. Vermeide auch duplicate indexes: Ein Index auf (status, is_deleted, created_at) beginnt bereits mit status, daher kann ein separater Index auf status ueberfluessig sein. Verwende SHOW INDEX FROM posts;, um vorhandene Indizes vor weiteren Aenderungen zu pruefen.

Indizes retten auch keine expressions, die den indexierten Wert verbergen. Wird etwa eine function auf eine Datumsspalte im Filter angewendet, kann das einen effizienten range lookup verhindern. Bevorzuge einen direkten Bereich, wenn er dieselbe Absicht ausdrueckt:

-- Prefer a searchable date range
SELECT id, title
FROM posts
WHERE created_at >= '2026-08-01 00:00:00'
  AND created_at < '2026-09-01 00:00:00';

Eine kleine, wiederholbare Index-Routine

Ich nutze eine einfache Routine statt einer dramatischen Datenbank-Tuning-Session. Erstens bestimme ich eine wichtige Seite oder einen Job. Zweitens sichere ich die exakte Query und untersuche sie mit EXPLAIN. Drittens pruefe ich bestehende Indizes und schlage einen Index vor, der zu Filtering und Ordering passt. Viertens teste ich bei wichtigen Tabellen auf einem Backup oder in einer Staging-Umgebung. Zum Schluss vergleiche ich Query-Zeit und execution plan nach der Aenderung und dokumentiere, warum der Index existiert.

Diese Routine ist absichtlich langweilig. Gute Wartung ist das meist. Sie schuetzt davor, Indizes hinzuzufuegen, weil ein Blogbeitrag sagte, sie seien schnell, und sie gibt der naechsten Person einen Grund, einen Index zu behalten oder zu entfernen. Plane Schema-Aenderungen in production sorgfaeltig, besonders bei grossen Tabellen, weil das Erstellen von Indizes je nach MySQL-Version und Operation weiterhin load und locking beeinflussen kann.

Die Datenbank den kurzen Weg nehmen lassen

Database Indexing ist kein Abzeichen fuer advanced engineering. Es ist grundlegende Ordnung: die Schubladen beschriften, die Menschen jeden Tag oeffnen. Beginne mit einer echten Query, beobachte ihren Plan, mache eine messbare Aenderung und pruefe das Ergebnis. Dieser Ansatz funktioniert fuer ein persoenliches CMS genauso wie fuer eine wachsende Business-Anwendung.

Wenn sich eine deiner Seiten schwerer anfuehlt, als sie sollte, untersuche ihre Query, bevor du nach einem groesseren Server greifst. Vielleicht braucht die Datenbank nicht mehr Leistung; sie braucht nur eine bessere Karte. Teile das Query-Pattern, das du gerade untersuchst, in den Kommentaren. Es kann jemand anderem helfen, ebenfalls den kurzen Weg zu finden.