Hinter den Kulissen der Performance: Wo und wie speichern Datenbanken ihre Indizes?

Wenn eine Datenbank eine Bibliothek ist, dann sind die Daten die Bücher in den Regalen, und Indizes sind der intelligente Katalog, mit dem Sie das richtige Buch in Sekunden finden, ohne jedes Regal zu durchsuchen. Jeder weiß, dass Indizes Suchen beschleunigen. Aber haben Sie sich jemals gefragt, wo diese Indizes physisch leben und wie sie unter der Haube strukturiert sind? Dies zu verstehen ist der Schlüssel zur wahren Optimierung.

Lassen Sie uns die Abstraktionen fallen lassen und hineinschauen.

Das Kernprinzip: Ein Index ist eine separate Datenstruktur

Es ist von Anfang an entscheidend zu verstehen: Ein Index wird nicht „zusammen" mit den Zeilendaten der Tabelle gespeichert. Er ist eine unabhängige, aber eng verknüpfte Struktur. Wenn Sie einen Index erstellen, erstellt und pflegt das DBMS ein spezielles Objekt, meist basierend auf balancierten Bäumen (B-Tree, B+Tree).

Wo also liegt er auf der Festplatte? Es gibt mehrere Optionen:

1. Im selben Tablespace wie die Tabelle selbst. Dies ist der gebräuchlichste Standardansatz (z. B. in PostgreSQL, MySQL InnoDB). Die Daten einer Tabelle und ihre Indizes sind verschiedene Mengen von Seiten (Blöcken) innerhalb derselben Datei(en). Bequem für die Verwaltung, kann aber zu I/O-Konkurrenz zwischen Daten- und Index-Lese-/Schreibvorgängen führen.
2. In einem separaten Tablespace oder auf einer separaten Festplatte. Dies ist eine fortgeschrittene Optimierungstechnik. Zum Beispiel können Sie Indizes auf einer schnellen SSD und seltener zugegriffene Daten auf einer langsameren HDD platzieren. Oder die I/O-Last verteilen. Dies ist in Oracle, SQL Server, PostgreSQL möglich.

Das Herz des Index: Die B+Tree-Struktur im Detail

Nahezu alle relationalen DBs verwenden einen B+Tree. Lassen Sie uns seine Anatomie visualisieren:

• Wurzel- und Nicht-Blattknoten: Enthalten Navigationsschlüssel (z. B. Werte der indizierten Spalte) und Zeiger auf Kindknoten. Dies ist das „Inhaltsverzeichnis" des Katalogs.
• Blattknoten: Dies ist der wichtigste Teil. Sie speichern die indizierten Schlüsselwerte und Zeiger (oder die tatsächlichen Zeilendaten selbst, im Fall eines clustered Index).

Auf der physischen Festplatte werden alle diese Baumknoten in Seiten oder Blöcken gespeichert — feste Speicherblöcke (typischerweise 4–16 KB). Seiten sind miteinander verknüpft, um die Baumstruktur zu bilden.

Sonderfälle und andere Strukturen

1. Hash-Indizes: Werden für Exact-Match-Suchen (=) verwendet. Sie sind eine Hash-Tabelle, bei der der Schlüssel der Hash-Wert der Spalte und der Wert ein Zeiger auf die Zeile ist. Sie werden in ihrem eigenen Speicher-/Festplattensegment gespeichert. Sehr schnell, aber nutzlos für Bereichsabfragen.
2. Bitmap-Indizes: Ideal für Spalten mit niedriger Kardinalität (Geschlecht, Status). Sie sind Arrays von Bitmaps. Sie werden in einem komprimierten Format gespeichert, was Speicherplatz spart. Jede Bitmap entspricht einem eindeutigen Wert.
3. Invertierte Indizes: Die Grundlage der Volltextsuche (FTS). Sie speichern Wörter (Token) und eine Liste von Dokumenten/Zeilen, in denen sie vorkommen. Dies sind spezialisierte Strukturen, die oft von separaten Engines verwaltet werden (wie Lucene in Elasticsearch).

Warum ist dieses praktische Wissen wichtig?

1. Abfrageleistung: Ein schlecht gestalteter Index (auf einer Spalte mit niedriger Kardinalität) belegt Speicherplatz, ohne Nutzen zu bringen.
2. Planung der Speicherplatzierung: In hochlastigen Systemen können Sie Indizes und Daten auf verschiedenen physischen Festplatten platzieren, um I/O-Konkurrenz zu reduzieren.
3. Wartung: Indizes fragmentieren bei häufigen Aktualisierungen. Operationen wie REINDEX oder REORGANIZE bauen sie neu auf und ordnen die Seiten physisch neu, für schnelleres sequenzielles Lesen.
4. Überwachung: Sie können Systemansichten abfragen (wie pg_stat_all_indexes in PG oder sys.indexes in SQL Server), um die Indexgröße auf der Festplatte und ihre Nutzungsstatistiken zu sehen.

Fazit: Indizes sind keine Magie; sie sind konkrete, physisch existierende Datenstrukturen. Ihre Effizienz hängt nicht nur von der Logik ab (welche Felder indiziert werden), sondern auch von der physischen Platzierung und der internen Mechanik. Ein tiefes Verständnis dieser Mechanismen unterscheidet einen guten Entwickler von einem echten Datenbankingenieur.