Wie funktioniert ein Datenbankindex, und wann macht ein zusätzlicher Index es schlimmer?

Ein Index ist eine separate sortierte Struktur, meist ein B-Baum, die Spaltenwerte auf Zeilenpositionen abbildet, damit die Engine seeken statt scannen kann. Er beschleunigt Reads, die auf diesen Spalten filtern oder sortieren. Er kostet dich bei Writes, weil jedes Insert, Update und Delete ihn pflegen muss, und er kostet Speicher. Spalten mit geringer Selektivität und Indizes, die niemand abfragt, sind meist ein Minusgeschäft.

Ein Index ist im Grunde eine sortierte Kopie einer oder mehrerer Spalten mit Zeigern zurück auf die Zeilen, meist ein B-Baum, damit die Engine binär suchen kann statt jede Page zu lesen. Damit wird aus einem Filter auf einer großen Tabelle statt eines Sequential Scan eine Handvoll Page Reads. Der Preis ist, dass jeder Write den Index mitpflegen muss, eine Tabelle mit acht Indizes zahlt beim Insert also achtmal, und Bulk Loads werden richtig langsam. Das andere, worauf ich achte, ist Selektivität. Wenn eine Spalte ein Boolean ist, das für neunzig Prozent der Zeilen true ist, scannt der Planner meistens einfach, weil wahlfreier Zugriff auf so viele Zeilen teurer ist als sequentiell zu lesen. Ich hatte einen Fall, in dem jemand einen Index auf eine status-Spalte mit drei Werten gelegt hat und sich überhaupt nichts verbessert hat. Geholfen hat am Ende ein zusammengesetzter Index auf tenant id und created at, passend zu Filter und Sortierung, damit die Datenbank seeken und dann in Reihenfolge lesen konnte, ohne einen separaten Sortierschritt.