Ein Hash-Index ist eine Indexstruktur, die über eine Hash-Funktion den Speicherort eines Eintrags direkt berechnet. Für Gleichheitssuchen (WHERE spalte = wert) ist er damit meist schneller als ein B-Baum: Die Suche läuft in O(1) statt O(log n), weil kein Baum durchlaufen werden muss.
Grenzen: keine Bereichsabfragen
Der Preis der Geschwindigkeit ist die fehlende Ordnung. Ein Hash-Index unterstützt keine Bereichsabfragen (BETWEEN, >, <), keine Sortierung und keine Präfixsuche — dafür wäre die sortierte Struktur eines B-Baums nötig. Deshalb ist der B-Baum der Allrounder, während der Hash-Index nur für exakte Treffer optimiert ist.
Wo Hash-Indizes vorkommen
- MySQL/MariaDB (InnoDB): Der Adaptive Hash Index wird automatisch auf häufig gesuchte B-Baum-Seiten im Buffer Pool aufgebaut — ohne manuelles CREATE INDEX.
- PostgreSQL: Hash-Indizes lassen sich explizit anlegen:
CREATE INDEX idx_email ON users USING hash (email). Sie waren früher nicht WAL-sicher, sind es aber seit PostgreSQL 10. - In-Memory-Engines: Speicherbasierte Systeme wie Redis oder Memcached verwenden Hash-Strukturen als Grundlage ihrer Schlüssel-Wert-Zugriffe — verwandt mit dem Key-Value-Store.
Wann lohnt sich ein Hash-Index?
Wenn die Anwendung überwiegend exakte Schlüsselsuchen macht (z. B. WHERE benutzer_id = 42) und keine Bereiche sortiert lesen muss, kann ein Hash-Index messbar schneller sein. In der Praxis reicht für die meisten Workloads ein B-Baum-Index, weil moderne Datenbanken den Abfrageplan ohnehin optimieren — der Hash-Index bleibt ein Spezialwerkzeug.
Verwandte Grundlagen: Query-Cache, Buffer Pool, B-Baum, Datenbank-Indizes, Query-Optimierung.