Alle Beiträge

Datenbank-Indizes, erklärt mit einem Telefonbuch

Datenbanken · 2 Min. Lesezeit ·

Jede langsame Abfrage, die ich je repariert habe, lief auf dasselbe Bild hinaus. Man fragt MySQL nach WHERE email = 'omar@example.com', und ohne Index kann die Datenbank nur eines tun:

Tabelle users · 1.000.000 Zeilen liest jede einzelne Zeile als würde man einen Namen im Telefonbuch suchen, indem man Seite 1, dann Seite 2, dann Seite 3 liest...
Ein vollständiger Tabellen-Scan. In Ordnung bei 1.000 Zeilen, schmerzhaft bei 1.000.000.

Was ein Index eigentlich ist

Ein Index ist eine zweite, sortierte Struktur neben deiner Tabelle: ein B-Baum. Sortierte Dinge lassen sich durch Halbieren durchsuchen, also macht die Datenbank Sprünge, keine Schritte. Dieselbe Abfrage, mit einem Index auf email:

A - Z A - M N - Z A - F G - M N - S T - Z Sprung 1 Sprung 2 Sprung 3: gefunden. Drei Lesevorgänge statt einer Million.
B-Baum-Suche: jeder Sprung halbiert den Suchraum oder besser.

Wann man einen Index hinzufügt

  • Spalten in WHERE, JOIN ... ON und ORDER BY deiner häufigen Abfragen.
  • Fremdschlüssel, immer.
  • Nicht auf Spalten, nach denen fast nie gefiltert wird: jeder Index verlangsamt Schreibvorgänge ein wenig.
Bevor du rätst, führe EXPLAIN auf der Abfrage aus. Siehst du type: ALL, ist das die erste Skizze: ein voller Scan. Mit dem richtigen Index wird daraus ref oder range, die zweite Skizze.

Die 20%-Performance-Verbesserung, die ich bei Getmayes geliefert habe, war größtenteils genau das: EXPLAIN-Ausgaben lesen, den Baum zeichnen, und die vier Indizes hinzufügen, die die Abfragen die ganze Zeit gebraucht hatten.

Notizen der Leser

  1. Noch keine Notizen. Die erste ist immer die mutigste.
Baust du etwas Ähnliches? Ich kann helfen. Kontakt