0Pricing
SQL Interview Prep · Lektion

Abdeckende Indizes und Index-Only-Scans

Spalten einbeziehen, damit eine Abfrage niemals auf den Tabellen-Heap zugreifen muss.

Abdeckende Indizes und Index-Only-Scans ist eine kostenlose SQL Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 3 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 SQL Interview Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Den Heap-Fetch wiederholen

Zuvor haben Sie gelernt, dass ein normaler B-Tree nur die indizierten Spalten und einen Zeiger auf die Zeile speichert. Nachdem der Index passende Zeilen gefunden hat, muss die Engine daher weiterhin zur Tabelle wechseln, um die übrigen Spalten zu lesen. Dieser Wechsel ist der Heap-Fetch – genau diese Kosten soll ein Covering-Index vermeiden.

In Vorstellungsgesprächen wird nach Covering-Indizes gefragt, um zu prüfen, ob Sie verstehen, warum ein Index eine Abfrage vollständig beantworten kann, ohne auf die Tabelle zuzugreifen.

Was „Covering“ bedeutet

Ein Index deckt eine Abfrage ab, wenn jede von der Abfrage benötigte Spalte aus SELECT, WHERE, ORDER BY und GROUP BY im Index selbst enthalten ist.

Wenn dies zutrifft, liest die Engine ausschließlich den Index und greift nie auf die Tabelle zu. PostgreSQL bezeichnet dies als Index Only Scan; SQL Server und andere Systeme sprechen von einem Covering-Index. Das Ergebnis sind weniger Seitenzugriffe und schnellere Abfragen.

Beispiel: Eine abgedeckte Abfrage

Angenommen, eine Abfrage benötigt nur customer_id und order_date. Ein zusammengesetzter Index genau auf diesen Spalten enthält alles, was die Abfrage verlangt, und kann daher allein aus dem Index beantwortet werden.

CREATE INDEX idx_orders_cust_date
  ON orders (customer_id, order_date);

-- Covered: both selected columns are in the index
SELECT customer_id, order_date
FROM orders
WHERE customer_id = 42;

Eine zusätzliche Spalte hebt die Abdeckung auf

Fügen Sie eine Spalte hinzu, die der Index nicht enthält, geht die Abdeckung verloren und die Engine muss den Heap abrufen, um diese Spalte zu lesen.

Hier ist total nicht im Index enthalten. Obwohl customer_id die Suche steuert, löst daher jede passende Zeile einen Heap-Fetch aus, um total zu lesen.

-- NOT covered: total is not in the index, forces heap fetches
SELECT customer_id, order_date, total
FROM orders
WHERE customer_id = 42;

Die INCLUDE-Klausel

Sie könnten total als vierte Schlüsselspalte hinzufügen. Wenn Sie aber nie danach filtern oder sortieren, wird dadurch unnötig Platz in der Sortierreihenfolge des Baums verbraucht. Das elegantere Werkzeug ist INCLUDE (von PostgreSQL und SQL Server unterstützt): Es speichert zusätzliche Spalten nur in den Blättern des Index als Nutzdaten und nicht als Teil des Sortierschlüssels.

Damit ist die Abfrage abgedeckt, ohne den durchsuchbaren Teil des Index aufzublähen.

CREATE INDEX idx_orders_cust_date_inc
  ON orders (customer_id, order_date)
  INCLUDE (total);

-- Now covered: total is carried in the leaf
SELECT customer_id, order_date, total
FROM orders
WHERE customer_id = 42;

Schlüsselspalten und enthaltene Spalten

Eine genaue Unterscheidung, mit der Sie im Vorstellungsgespräch punkten:

  • Schlüsselspalten legen die Sortierreihenfolge fest und können für gezielte Suchen und Bereichsscans verwendet werden. Für sie gilt die Regel des linken Präfixes.
  • Enthaltene Spalten werden nur in den Blättern als zusätzliche Daten gespeichert. Sie können nicht durchsucht werden, ermöglichen aber die Abdeckung weiterer Abfragen.

Als Faustregel gilt: Spalten, nach denen Sie filtern oder sortieren, gehören in den Schlüssel; Spalten, die Sie nur zurückgeben, gehören in INCLUDE.

MySQL/InnoDB: Die Besonderheit des Clustered Index

Zeigen Sie, dass Sie sich mit verschiedenen SQL-Dialekten auskennen. InnoDB-Tabellen (MySQL) sind nach dem Primärschlüssel geclustert: Sekundärindizes enthalten implizit die Spalten des Primärschlüssels. Daher deckt ein Sekundärindex automatisch jede Abfrage ab, die nur die indizierten Spalten und Primärschlüsselspalten auswählt; eine INCLUDE-Klausel ist nicht erforderlich (MySQL unterstützt INCLUDE nicht).

Das Konzept der Abdeckung ist universell, aber Syntax und automatisch enthaltene Spalten unterscheiden sich je nach Engine.

Einen Index Only Scan überprüfen

Belegen Sie die Abdeckung mit EXPLAIN. In PostgreSQL enthält der Ausführungsplan den Knoten Index Only Scan statt Index Scan. Achten Sie in EXPLAIN (ANALYZE) auf Heap Fetches: 0; das ist das eindeutige Zeichen dafür, dass kein Tabellenzugriff stattgefunden hat.

Wenn Sie einen Index Only Scan erwartet haben, aber einen Index Scan mit Heap-Fetches sehen, fehlt eine ausgewählte Spalte im Index.

EXPLAIN (ANALYZE)
SELECT customer_id, order_date, total
FROM orders
WHERE customer_id = 42;
-- Look for: Index Only Scan ... Heap Fetches: 0

Der Vorbehalt zur Visibility Map in Postgres

Ein subtiler PostgreSQL-Punkt, der einen Bonuspunkt wert ist: Ein Index Only Scan kann weiterhin auf den Heap zugreifen, wenn eine Seite in der Visibility Map nicht als vollständig sichtbar markiert ist. Führen Sie nach umfangreichen Aktualisierungen VACUUM aus, damit die Visibility Map aktuell ist. Andernfalls steigt die Zahl der Heap Fetches und der Vorteil des „Index Only“-Scans schrumpft.

-- Keeps the visibility map fresh so index-only scans stay heap-free
VACUUM ANALYZE orders;

Wann Sie keinen breiten Covering-Index erstellen sollten

Covering-Indizes sind nicht kostenlos. Wenn Sie viele Spalten in INCLUDE aufnehmen, wird der Index groß, verbraucht Cache und verlangsamt Schreibvorgänge, da jede relevante Änderung den Index aktualisiert. Diese Abwägungen sollten Sie nennen:

  • Sehr gut für häufig ausgeführte, schmale Leseabfragen.
  • Schlecht als Sammelbecken für jede Spalte „nur für alle Fälle“.

Decken Sie die wichtige Abfrage ab, nicht die gesamte Zeile.

So formulieren Sie es im Vorstellungsgespräch

Eine prägnante Zusammenfassung:

„Ein Covering-Index enthält jede Spalte, auf die eine Abfrage zugreift. Dadurch beantwortet die Engine die Abfrage allein aus dem Index – als Index Only Scan – und überspringt den Heap-Fetch. Ich lege durchsuchte Spalten in den Schlüssel und ausschließlich zurückgegebene Spalten in INCLUDE, überprüfe mit EXPLAIN ANALYZE, dass Heap Fetches null sind, und halte den Index schmal, um die Schreibgeschwindigkeit zu schützen.“

Kurzer Check

Überlegen Sie, ob die Abdeckung gegeben ist und wo die einzelnen Spalten hingehören.

Zusammenfassung: Covering-Indizes

Die wichtigsten Erkenntnisse:

  • Ein Index deckt eine Abfrage ab, wenn er jede von ihr benötigte Spalte enthält und dadurch einen Index Only Scan ohne Heap-Fetch ermöglicht.
  • Schlüsselspalten steuern gezielte Suchen und folgen der Regel des linken Präfixes; INCLUDE-Spalten sind Nutzdaten, die nur in den Blättern liegen und die Abdeckung ermöglichen.
  • Sekundärindizes in InnoDB enthalten implizit den Primärschlüssel.
  • Überprüfen Sie dies mit EXPLAIN (ANALYZE) und achten Sie auf Heap Fetches. Halten Sie in Postgres VACUUM aktuell.
  • Halten Sie Covering-Indizes schmal, um die Schreibleistung zu schützen.

Als Nächstes: die Kehrseite – wann Indizes tatsächlich schaden.

Häufig gestellte Fragen

Ist die Lektion „Abdeckende Indizes und Index-Only-Scans“ kostenlos?

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

Was lerne ich in „Abdeckende Indizes und Index-Only-Scans“?

Spalten einbeziehen, damit eine Abfrage niemals auf den Tabellen-Heap zugreifen muss. Du übst SQL 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 SQL Interview Prep zu starten?

Keine Vorkenntnisse erforderlich. SQL 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 3 von 4.

Wie lange dauert die Lektion „Abdeckende Indizes und Index-Only-Scans“?

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 SQL Interview Prep-Lektion Code schreiben und ausführen?

Ja. Jede SQL 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 SQL Interview Prep