0Pricing
SQL Interview Prep · Lektion

Einen EXPLAIN-Plan lesen

Scan-Typen, Join-Verfahren und Kostenschätzungen in einem Abfrageplan interpretieren.

Einen EXPLAIN-Plan lesen ist eine kostenlose SQL Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 1 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.

Warum Interviewer nach EXPLAIN fragen

Sobald Sie ein Senior-Screening erreichen, fragen Interviewer nicht mehr Schreiben Sie eine Abfrage, sondern Warum ist diese Abfrage langsam? Das Tool, das diese Frage beantwortet, ist EXPLAIN.

EXPLAIN zeigt den Ausführungsplan der Datenbank: die schrittweise Strategie, die der Planer für die Ausführung Ihres SQL gewählt hat. Der Plan zeigt, welche Tabellen gescannt werden, in welcher Reihenfolge sie verknüpft werden und wie teuer die einzelnen Schritte ungefähr sind.

Wenn Sie einen Plan lesen können, zeigt das, dass Sie die Datenbank-Engine und nicht nur die Syntax verstehen. Genau diese Fähigkeit nutzen Interviewer, um Entwickler auf mittlerer Ebene von Senior-Entwicklern zu unterscheiden.

EXPLAIN oder EXPLAIN ANALYZE

Es gibt zwei Varianten, und Interviewer fragen gern nach dem Unterschied.

  • EXPLAIN zeigt den geschätzten Plan des Planers, ohne die Abfrage auszuführen. Schnell und sicher.
  • EXPLAIN ANALYZE führt die Abfrage tatsächlich aus und gibt neben den Schätzungen die tatsächlichen Zeilenanzahlen und Laufzeiten aus.

Besonders aufschlussreich ist der Vergleich der geschätzten mit den tatsächlichen Zeilen. Eine große Abweichung bedeutet, dass der Planer über schlechte Statistiken verfügt und wahrscheinlich eine ungünstige Entscheidung trifft.

Achtung: EXPLAIN ANALYZE führt die Abfrage tatsächlich aus. Daher werden alle INSERT- oder UPDATE-Operationen ausgeführt, sofern die Abfrage nicht in eine zurückgerollte Transaktion eingeschlossen ist.

EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 42;

So lesen Sie den Baum

Ein Plan ist ein Baum, keine Liste. Die am stärksten eingerückten Knoten sind die Blätter, die zuerst ausgeführt werden; Ergebnisse fließen nach oben zur Wurzel, die die endgültige Ausgabe erzeugt.

Lesen Sie den Plan von innen nach außen: Suchen Sie den am tiefsten eingerückten Knoten – dort beginnt die Ausführung. Jeder übergeordnete Knoten verarbeitet die Zeilen, die seine untergeordneten Knoten ausgeben.

Beschreiben Sie es im Interview genau so: Zuerst scannen wir diese Tabelle, diese Zeilen fließen in diesen Join, der Join fließt in die Sortierung, und die Sortierung fließt in das Limit. Diese Erläuterung von unten nach oben möchten die Interviewer hören.

Anatomie eines Plan-Knotens

Jeder Knoten in einem Postgres-Plan enthält dieselben wichtigen Kennzahlen:

  • cost=0.00..35.50 Startkosten..Gesamtkosten in beliebigen Einheiten des Planners
  • rows=1000 geschätzte Anzahl der erzeugten Zeilen
  • width=64 geschätzte durchschnittliche Größe einer Zeile in Byte

Die ersten Kosten sind die Startup-Kosten (Arbeit, die vor dem Erscheinen der ersten Zeile anfällt, etwa beim Erstellen einer Hash-Tabelle). Die zweiten Kosten sind die Gesamtkosten für die Rückgabe aller Zeilen. Höhere Gesamtkosten entsprechen der Schätzung des Planners für einen höheren relativen Aufwand.

Seq Scan on orders  (cost=0.00..35.50 rows=1000 width=64)

Ein durchgearbeitetes Beispiel

Betrachten Sie eine einfache Abfrage mit Filter. Der folgende Plan erzählt die ganze Geschichte in einer Zeile.

Es handelt sich um einen Seq Scan (vollständiges Lesen der Tabelle) für orders, bei dem der Filter status = 'shipped' angewendet wird. Der Planner schätzt 1000 übereinstimmende Zeilen.

Wenn orders 10 Millionen Zeilen enthält und nur 1000 davon übereinstimmen, erwartet ein Interviewer von Ihnen die Aussage: Ein Sequential Scan ist hier ineffizient; ein Index auf status (oder auf einer selektiveren Spalte) würde es uns ermöglichen, nicht die gesamte Tabelle lesen zu müssen.

EXPLAIN SELECT * FROM orders WHERE status = 'shipped';

Seq Scan on orders  (cost=0.00..18334.00 rows=1000 width=64)
  Filter: (status = 'shipped'::text)

Geschätzte und tatsächliche Zeilenanzahl

Mit EXPLAIN ANALYZE erhalten Sie zusätzlich tatsächliche Zahlen in Klammern.

Sehen Sie sich das Beispiel an: Der Planner hat 1000 Zeilen geschätzt, tatsächlich aber 480000 erhalten. Das ist eine 480-fache Unterschätzung. Der Planner hat seine Strategie unter der Annahme weniger Zeilen gewählt, daher ist seine Wahl für die realen Daten wahrscheinlich falsch.

In Vorstellungsgesprächen ist diese Abweichung Ihre zentrale Diagnose: Die Statistiken sind veraltet; führen Sie ANALYZE für die Tabelle aus, dann wird der Planner wahrscheinlich einen besseren Plan wählen.

Seq Scan on orders
  (cost=0.00..18334.00 rows=1000 width=64)
  (actual time=0.02..210.4 rows=480000 loops=1)

Was loops=N bedeutet

Der Wert loops ist wichtiger, als viele Bewerber erwarten. Er gibt an, wie oft ein Knoten ausgeführt wurde.

Dieser Wert erscheint auf der inneren Seite eines Nested-Loop-Joins: Der innere Knoten wird einmal pro Zeile der äußeren Seite ausgeführt. Bei loops=480000 wurde dieser innere Schritt 480.000-mal ausgeführt.

Wichtig: Die angezeigte Zeit pro Zeile und die Zeilenanzahl gelten pro Schleifendurchlauf. Um den tatsächlichen Gesamtwert zu erhalten, multiplizieren Sie ihn mit loops. Ein Knoten, der mit 0.004ms pro Durchlauf günstig aussieht, benötigt bei 480000 Durchläufen fast 2 Sekunden.

Index Scan using idx_cust on orders
  (actual time=0.003..0.004 rows=1 loops=480000)

Relative Kosten statt Millisekunden

Eine häufige Falle: Bewerber lesen cost=18334 und sagen Das dauert 18 Sekunden. Das ist falsch.

Die Kosten werden in beliebigen Einheiten des Planners angegeben und so kalibriert, dass das sequentielle Lesen einer Seite 1.0 entspricht. Sie sind nur zum Vergleichen von Plänen untereinander sinnvoll, nicht als Angabe der tatsächlichen Laufzeit.

Für die tatsächliche Zeit benötigen Sie EXPLAIN ANALYZE und dessen Werte für actual time, die in Millisekunden gemessen werden. Sagen Sie das im Vorstellungsgespräch klar; dadurch zeigen Sie, dass Sie die Kennzahl wirklich verstehen.

Einen Join-Plan lesen

Hier sehen Sie einen Plan für zwei Tabellen. Lesen Sie ihn von unten nach oben.

Die ersten beiden Scans sammeln Zeilen aus orders und customers. Sie speisen einen Hash Join: Eine Seite wird gehasht, während die andere den Hash abfragt. Die Ausgabe des Joins wird anschließend an das endgültige Ergebnis weitergegeben.

Beachten Sie, dass die Einrückung die Struktur zeigt: Beide Scans sind dem Hash Join untergeordnet. Der Interviewer möchte, dass Sie die Join-Methode identifizieren (hier ein Hash) und erkennen, welche Tabelle gehasht wird (in der Regel die kleinere).

Hash Join  (cost=30.0..520.0 rows=900 width=72)
  Hash Cond: (o.customer_id = c.id)
  ->  Seq Scan on orders o  (cost=0..400 rows=10000)
  ->  Hash  (cost=18..18 rows=500)
        ->  Seq Scan on customers c  (cost=0..18 rows=500)

Warnsignale, die Sie nennen sollten

Schärfen Sie Ihren Blick für diese Warnsignale in jedem Plan:

  • Seq Scan auf einer riesigen Tabelle mit einem selektiven Filter; ein Index könnte helfen.
  • Geschätzte Zeilenanzahl weicht stark von der tatsächlichen ab; die Statistiken sind veraltet.
  • Nested Loop mit vielen loops über eine große Tabelle; häufig fehlt ein Index für den inneren Join-Schlüssel.
  • Sort oder Hash lagert auf die Festplatte aus (angezeigt als Disk-Nutzung); work_mem ist zu klein.
  • Sehr hoher Wert bei Rows Removed by Filter; Sie haben den größten Teil der Tabelle gelesen und verworfen.

Ausgabeformate und BUFFERS

Pläne gibt es in mehreren Formaten. Das standardmäßige TEXT ist das Format, das Sie in Vorstellungsgesprächen vorlesen. Sie können aber auch strukturierte Ausgaben anfordern.

EXPLAIN (FORMAT JSON) oder FORMAT YAML erzeugt maschinenlesbare Pläne, die von Tools und Dashboards analysiert werden. Sie brauchen diese selten manuell, aber es ist ein guter Pluspunkt für Senior-Entwickler, ihre Existenz zu kennen.

Fügen Sie Optionen in Klammern hinzu: EXPLAIN (ANALYZE, BUFFERS). Die Option BUFFERS gibt Cache-Treffer im Vergleich zu Festplattenlesevorgängen an, was bei der Diagnose von I/O-limitierten Abfragen sehr hilfreich ist.

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE customer_id = 42;

Kurze Überprüfung

Ein Interviewer zeigt Ihnen einen EXPLAIN ANALYZE-Knoten mit rows=1000 im Kostenabschnitt, aber mit actual ... rows=480000. Welche Diagnose ist am wahrscheinlichsten?

Zusammenfassung

Sie können einen Plan jetzt wie ein Senior-Entwickler lesen:

  • EXPLAIN erstellt Schätzungen, EXPLAIN ANALYZE führt den Plan aus und misst ihn.
  • Lesen Sie den Baum von unten nach oben; die Blätter werden zuerst ausgeführt, die Wurzel erzeugt die Ausgabe.
  • Jeder Knoten zeigt cost (relative Einheiten), rows und width; actual time ist der tatsächliche Wert in Millisekunden.
  • loops multipliziert die Werte pro Durchlauf; achten Sie auf Nested Loops.
  • Die Abweichung zwischen geschätzter und tatsächlicher Zeilenanzahl ist Ihr wichtigstes diagnostisches Signal.

Beschreiben Sie den Plan laut und weisen Sie auf Warnsignale hin – genau dieses Verhalten überzeugt im Vorstellungsgespräch.

Häufig gestellte Fragen

Ist die Lektion „Einen EXPLAIN-Plan lesen“ kostenlos?

Ja — der vollständige Text von „Einen EXPLAIN-Plan lesen“ 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 „Einen EXPLAIN-Plan lesen“?

Scan-Typen, Join-Verfahren und Kostenschätzungen in einem Abfrageplan interpretieren. 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 1 von 4.

Wie lange dauert die Lektion „Einen EXPLAIN-Plan lesen“?

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. Einen EXPLAIN-Plan lesen
  2. Seq Scan, Index Scan und Index-Only
  3. Join-Algorithmen: Nested Loop, Hash, Merge
  4. Langsame Abfragen erkennen und beheben
← Zurück zu SQL Interview Prep