0Pricing
Coding Interview Prep · Lektion

Wann Indizes schaden: Schreibvorgänge und Selektivität

Schreibverstärkung und warum ein Index auf einer Spalte mit geringer Selektivität nutzlos ist.

Wann Indizes schaden: Schreibvorgänge und Selektivität ist eine kostenlose Coding Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Coding Interview Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Coding Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Die Frage hinter der Frage

Nach drei Lektionen darüber, warum Indizes helfen, drehen Interviewer die Frage um: „Warum nicht einfach jede Spalte indizieren?“ Ein starker Kandidat erklärt, dass Indizes reale Kosten verursachen – bei Schreibvorgängen sowie bei Cache und Speicherplatz – und dass der Planer manche Indizes niemals verwenden wird.

Diese Lektion behandelt die beiden wichtigsten Gründe, aus denen ein Index schaden kann: Schreibverstärkung und geringe Selektivität.

Jeder Index verlangsamt Schreibvorgänge

Ein Index muss mit der Tabelle synchron bleiben. Jedes INSERT, jedes DELETE und jedes UPDATE einer indizierten Spalte muss auch die Indexstruktur aktualisieren. Das ist Schreibverstärkung: Aus einer Änderung an einer Zeile werden eine Tabellenschreibung plus eine Schreiboperation für jeden betroffenen Index.

Eine Tabelle mit acht Indizes verursacht ungefähr neunmal so viel Schreibarbeit wie eine nicht indizierte Tabelle. Bei schreibintensiven Tabellen oder Tabellen mit hohem Durchsatz ist das eine erhebliche Belastung.

Beispiel: Die Schreibkosten

Stellen Sie sich eine Ereignistabelle vor, in die Tausende Zeilen pro Sekunde geschrieben werden. Jeder zusätzliche Index sorgt dafür, dass jeder Einfügevorgang mehr Arbeit verursacht, Indexseiten aufteilt, Blätter aktualisiert und mit anderen Zugriffen um Cache konkurriert.

Bei einer ausschließlich durch Anhängen wachsenden, schreibdominierten Tabelle lautet die richtige Antwort oft: wenige oder keine Indizes über den Primärschlüssel hinaus und umfangreiche Lesevorgänge stattdessen auf einem Replikat oder in einem Data Warehouse ausführen.

-- Each of these indexes adds cost to EVERY insert below
CREATE INDEX ix_events_user ON events (user_id);
CREATE INDEX ix_events_type ON events (event_type);
CREATE INDEX ix_events_ts   ON events (created_at);

INSERT INTO events (user_id, event_type, created_at)
VALUES (42, 'click', now());  -- now updates table + 3 indexes

Was Selektivität bedeutet

Selektivität beschreibt, wie gut eine Spalte Zeilen unterscheidet – also den Anteil der Zeilen, auf den ein typischer Wert zutrifft. Hohe Selektivität bedeutet wenige Zeilen pro Wert, etwa bei einer E-Mail-Adresse oder einer UUID. Geringe Selektivität bedeutet viele Zeilen pro Wert, etwa bei einem booleschen Wert oder einem Status mit drei möglichen Werten.

Indizes lohnen sich bei Spalten mit hoher Selektivität, weil eine Suche dort fast alle Zeilen ausschließt. Bei Spalten mit geringer Selektivität ist das häufig nicht der Fall.

Warum ein Index mit geringer Selektivität nutzlos ist

Angenommen, is_active ist für 90 % der Benutzer auf true gesetzt. Eine Indexsuche würde 90 % der Tabelle zurückgeben. Für so viele Zeilen müsste die Engine jeweils einen Heap-Fetch ausführen, was langsamer wäre, als die Tabelle einfach in einem sequenziellen Durchlauf zu scannen.

Der Planer ignoriert den Index daher zu Recht und führt einen sequenziellen Scan aus. Der Index verursacht dann nur Schreibaufwand und Speicherverbrauch, ohne irgendeinen Vorteil beim Lesen zu bieten.

-- 90% of rows match: the planner will likely skip this index
CREATE INDEX ix_users_active ON users (is_active);
SELECT * FROM users WHERE is_active = true;

Der grobe Schwellenwert

Eine nützliche Faustregel, die Sie nennen können: Wenn eine Bedingung auf mehr als ungefähr 5 bis 20 % einer Tabelle zutrifft, ist ein sequenzieller Scan normalerweise schneller als ein Index-Scan, weil zufällige Heap-Fetches mehr kosten, als Seiten der Reihe nach zu lesen.

Der genaue Umschlagpunkt hängt von der Zeilengröße, der Zwischenspeicherung und der Speichergeschwindigkeit ab. Deshalb verwendet der Planer Statistiken und keine feste Zahl für seine Entscheidung.

Partielle Indizes als Lösung

Wenn Sie bei einer schief verteilten Spalte immer nur nach den seltenen Werten suchen, indiziert ein partieller Index (Postgres) nur diese Zeilen – klein, selektiv und kostengünstig zu pflegen.

Wenn 1 % der Bestellungen den Status pending haben und Sie genau diese ständig abfragen, indizieren Sie nur sie. Der Index bleibt klein und der Planer verwendet ihn gerne.

-- Index only the rare, frequently-queried rows
CREATE INDEX ix_orders_pending
  ON orders (created_at)
  WHERE status = 'pending';

Veraltete Statistiken führen den Planer in die Irre

Der Optimierer entscheidet anhand von Spaltenstatistiken zwischen Index und Scan. Wenn diese nach einem Massenimport oder einer umfangreichen Aktualisierung veraltet sind, kann er die Selektivität falsch einschätzen und den falschen Plan auswählen.

Wenn ein Interviewer sagt: „Der Index existiert, wird aber nicht verwendet“, gehört zu einer sehr guten Antwort, zunächst die Statistiken mit ANALYZE zu aktualisieren, statt sofort den Index selbst verantwortlich zu machen.

ANALYZE orders;  -- refresh planner statistics

Weitere Nachteile von Indizes

Ergänzen Sie Ihre Antwort um die weniger bekannten Kosten:

  • Speicherplatz und Cache: Indizes belegen Speicherplatz und konkurrieren um Arbeitsspeicher, wodurch nützliche Datenseiten verdrängt werden.
  • Redundante oder überlappende Indizes: Sie werden gepflegt, aber nie ausgewählt.
  • Aufblähung: Bei umfangreichen Aktualisierungen fragmentieren B-Trees und benötigen REINDEX.
  • Verwirrung des Optimierers: Zu viele ähnliche Indizes machen die Planung langsamer und weniger vorhersehbar.

Nicht verwendete Indizes finden

Um eine Bereinigung in der Praxis zu begründen, erwähnen Sie, dass Postgres die Indexnutzung erfasst. Indizes mit idx_scan = 0 kommen für eine Entfernung infrage: Sie verursachen Schreibaufwand und benötigen Speicherplatz, bedienen aber niemals eine Leseabfrage.

SELECT relname AS table_name, indexrelname AS index_name, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY relname;

So formulieren Sie es im Vorstellungsgespräch

Eine vollständige und ausgewogene Zusammenfassung:

„Indizes verursachen Schreibverstärkung: Bei jedem INSERT, UPDATE und DELETE müssen sie gepflegt werden. Außerdem erhöhen sie den Druck auf Speicherplatz und Cache. Sie lohnen sich nur bei Bedingungen mit hoher Selektivität. Bei einer Spalte, auf die die meisten Zeilen zutreffen, bevorzugt der Planer zu Recht einen sequenziellen Scan, sodass der Index nur zusätzlichen Aufwand verursacht. Bei schief verteilten Spalten greife ich auf einen partiellen Index zurück, halte die Statistiken mit ANALYZE aktuell und entferne nicht verwendete Indizes.“

Kurzer Check

Entscheiden Sie, welcher Index seine Kosten wahrscheinlich am wenigsten rechtfertigt.

Zusammenfassung: Wann Indizes schaden

Die wichtigsten Erkenntnisse:

  • Jeder Index verursacht Schreibverstärkung sowie zusätzliche Kosten für Speicherplatz und Cache.
  • Indizes helfen bei Spalten mit hoher Selektivität; bei Spalten mit geringer Selektivität bevorzugt der Planer einen sequenziellen Scan.
  • Wenn ungefähr 5 bis 20 % der Zeilen betroffen sind, gewinnt normalerweise der Scan.
  • Verwenden Sie bei schief verteilten Spalten, die Sie nur nach den seltenen Werten abfragen, einen partiellen Index.
  • Halten Sie Statistiken mit ANALYZE aktuell und entfernen Sie nicht verwendete Indizes (idx_scan = 0).

Damit ist der Kurs zur Indexstrategie abgeschlossen: Erstellen Sie Indizes dort, wo sie sich lohnen, und belegen Sie dies mit dem Ausführungsplan.

Häufig gestellte Fragen

Ist die Lektion „Wann Indizes schaden: Schreibvorgänge und Selektivität“ kostenlos?

Ja — der vollständige Text von „Wann Indizes schaden: Schreibvorgänge und Selektivität“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Coding Interview Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Coding Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Wann Indizes schaden: Schreibvorgänge und Selektivität“?

Schreibverstärkung und warum ein Index auf einer Spalte mit geringer Selektivität nutzlos ist. Du übst Coding Interview Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Coding Interview Prep zu starten?

Keine Vorkenntnisse erforderlich. Coding Interview Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Wann Indizes schaden: Schreibvorgänge und Selektivität“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Coding Interview Prep-Lektion Code schreiben und ausführen?

Ja. Jede Coding Interview Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. B-Tree-Indizes und ihr Nutzen
  2. Spaltenreihenfolge in zusammengesetzten Indizes
  3. Abdeckende Indizes und Index-Only-Scans
  4. Wann Indizes schaden: Schreibvorgänge und Selektivität
← Zurück zu Coding Interview Prep