EXPLAIN-Plaene lesen lernen, datenbankuebergreifend

1. Warum ein EXPLAIN-Plan trotz unterschiedlicher Datenbanken vergleichbar ist

Jede relationale Datenbank besitzt einen Optimizer, der aus einer SQL-Anweisung einen konkreten Ausfuehrungsplan erzeugt. Dieser Plan beschreibt, in welcher Reihenfolge Tabellen gelesen werden, welche Zugriffspfade genutzt werden und wie Zwischenergebnisse kombiniert werden. Der EXPLAIN-Plan ist das Fenster in diese Entscheidung, und obwohl MySQL, PostgreSQL, SQL Server und Oracle unterschiedliche Ausgabeformate verwenden, folgen sie alle demselben Grundprinzip: ein Baum aus Operationen, bei dem Kosten von unten nach oben aufsummiert werden.

Wer einmal gelernt hat, einen EXPLAIN-Plan konzeptionell zu lesen, kann dieses Wissen auf jede relationale Datenbank uebertragen. Die Begriffe unterscheiden sich, "Index Scan" in PostgreSQL entspricht konzeptionell "Index Seek" in SQL Server, aber die zugrunde liegende Frage bleibt identisch: Liest die Datenbank moeglichst wenige Zeilen, um das Ergebnis zu berechnen, oder verschwendet sie Arbeit durch vollstaendige Tabellenscans und ungeschickte Join-Reihenfolgen? Dieser Artikel zeigt, wie man einen EXPLAIN-Plan systematisch liest, unabhaengig vom konkreten Datenbanksystem im Einsatz.

Der praktische Nutzen ist direkt: Ein Entwickler, der einen EXPLAIN-Plan interpretieren kann, muss nicht mehr raten, warum eine Abfrage langsam ist. Er sieht schwarz auf weiss, welcher Schritt im Plan die meiste Zeit oder die meisten geschaetzten Kosten verursacht, und kann gezielt dort ansetzen, statt wahllos Indizes hinzuzufuegen oder die Abfrage umzuschreiben.

2. Der Ausfuehrungsplan als Baum: Knoten, Reihenfolge, Kosten

Ein EXPLAIN-Plan ist strukturell ein Baum aus Operationsknoten. Blattknoten lesen Daten direkt aus Tabellen oder Indizes, innere Knoten kombinieren die Ergebnisse ihrer Kindknoten, etwa durch einen Join, eine Sortierung oder eine Aggregation. Die Wurzel des Baums liefert das Endergebnis der Abfrage. Wichtig fuer das Lesen: Die Ausfuehrung beginnt an den Blaettern und arbeitet sich nach oben zur Wurzel, auch wenn die textuelle Darstellung in manchen Tools von oben nach unten gelesen wird.

Jeder Knoten im EXPLAIN-Plan traegt geschaetzte Kennzahlen: die erwartete Anzahl Zeilen, die geschaetzten Kosten in einer abstrakten Einheit und oft die geschaetzte Startzeit sowie Gesamtzeit. PostgreSQL zeigt Kosten als zwei Zahlen, "cost=0.29..8.31" bedeutet Startkosten bis zur ersten Zeile und Gesamtkosten bis zur letzten Zeile. MySQL zeigt in FORMAT=JSON aehnliche Werte unter "cost_info". Diese Zahlen sind relative Einheiten, keine Millisekunden, und dienen dem Optimizer zum Vergleich alternativer Plaene, nicht als absolute Zeitangabe.

Beim Lesen eines EXPLAIN-Plans lohnt es sich, zuerst die grobe Struktur zu erfassen: Wie viele Tabellen sind beteiligt, welche Join-Operationen verbinden sie, und an welcher Stelle im Baum entstehen die hoechsten Kosten. Erst danach lohnt der Blick auf Details wie einzelne Filterbedingungen. Diese Top-down-Strategie verhindert, dass man sich in Details eines einzelnen Blattknotens verliert, waehrend das eigentliche Problem an ganz anderer Stelle im Baum liegt.

-- PostgreSQL: EXPLAIN without execution, tree structure visible in indentation
EXPLAIN
SELECT c.customer_name, o.order_date, o.total_amount
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.order_date >= '2026-01-01'
ORDER BY o.order_date DESC;

-- Typical output (indentation shows the tree, deepest node runs first)
-- Sort  (cost=1245.31..1247.81 rows=1000 width=48)
--   Sort Key: o.order_date DESC
--   ->  Hash Join  (cost=88.00..1195.31 rows=1000 width=48)
--         Hash Cond: (o.customer_id = c.customer_id)
--         ->  Seq Scan on orders o  (cost=0.00..1080.00 rows=1000 width=24)
--               Filter: (order_date >= '2026-01-01'::date)
--         ->  Hash  (cost=63.00..63.00 rows=2000 width=32)
--               ->  Seq Scan on customers c  (cost=0.00..63.00 rows=2000 width=32)

3. Scan-Typen erkennen: Full Table Scan, Index Scan, Index Seek

Der Scan-Typ an jedem Blattknoten eines EXPLAIN-Plans entscheidet massgeblich ueber die Performance einer Abfrage. Ein Full Table Scan, in PostgreSQL "Seq Scan" genannt, in MySQL "ALL" im type-Feld, liest jede einzelne Zeile einer Tabelle und prueft sie gegen die Filterbedingung. Bei kleinen Tabellen ist das oft schneller als ein Index-Zugriff, weil der Overhead der Indexnavigation entfaellt. Bei grossen Tabellen mit selektiven Filtern ist ein Full Table Scan dagegen fast immer ein Warnsignal im EXPLAIN-Plan.

Ein Index Scan liest gezielt ueber einen Index und greift danach fuer jede gefundene Zeile auf die eigentliche Tabelle zu, um weitere Spalten zu laden, sofern diese nicht im Index selbst enthalten sind. Dieser zusaetzliche Zugriff wird als "Heap Fetch" in PostgreSQL oder als Bookmark-Lookup in SQL Server bezeichnet und kostet bei vielen Treffern deutlich mehr als ein reiner Index-Zugriff. Ein Index Only Scan, beziehungsweise eine "Covering Index"-Nutzung, vermeidet diesen zusaetzlichen Zugriff komplett, weil alle benoetigten Spalten bereits im Index vorhanden sind, das ist im EXPLAIN-Plan meist der guenstigste Zugriffspfad.

MySQL unterscheidet im EXPLAIN-Output zusaetzlich zwischen "ref", "range", "const" und "eq_ref" als Zugriffstypen, jeweils mit unterschiedlicher Selektivitaet. "const" bedeutet, dass hoechstens eine Zeile ueber einen Primary- oder Unique-Key gefunden wird, "range" durchsucht einen begrenzten Wertebereich eines Index. Diese feingranulare Klassifizierung im EXPLAIN-Plan hilft dabei, die tatsaechliche Selektivitaet eines Zugriffs einzuschaetzen, ohne die zugrunde liegenden Daten selbst zu kennen.

-- MySQL: EXPLAIN classic output shows the access type column directly
EXPLAIN SELECT * FROM orders WHERE customer_id = 4821;
-- id | table  | type  | key         | rows | Extra
--  1 | orders | ref   | idx_cust_id |   12 | NULL
-- type=ref means an index lookup on a non-unique key, much cheaper than ALL

EXPLAIN SELECT * FROM orders WHERE order_id = 90142;
-- id | table  | type  | key     | rows | Extra
--  1 | orders | const | PRIMARY |    1 | NULL
-- type=const means a single-row lookup via a unique key, the cheapest access type

4. Join-Strategien im Plan: Nested Loop, Hash Join, Merge Join

Die Join-Strategie, die im EXPLAIN-Plan gewaehlt wird, bestimmt massgeblich die Laufzeit bei mehreren beteiligten Tabellen. Ein Nested Loop Join iteriert fuer jede Zeile der aeusseren Tabelle ueber passende Zeilen der inneren Tabelle. Diese Strategie ist effizient, wenn die aeussere Tabelle wenige Zeilen liefert und fuer die innere Tabelle ein passender Index existiert. Bei grossen Zeilenmengen auf beiden Seiten wird ein Nested Loop dagegen schnell zum Flaschenhals, weil die Anzahl der inneren Durchlaeufe linear mit der aeusseren Zeilenzahl waechst.

Ein Hash Join baut aus der kleineren Tabelle eine Hash-Tabelle im Speicher auf und durchsucht sie fuer jede Zeile der groesseren Tabelle. Diese Strategie skaliert gut bei grossen, unsortierten Datenmengen, benoetigt aber ausreichend Arbeitsspeicher. Reicht der Speicher nicht aus, muss die Datenbank auf Platte ausweichen, was im EXPLAIN-Plan oft als "Batches" grosser eins in PostgreSQL sichtbar wird und ein klares Performance-Signal ist. Ein Merge Join schliesslich verbindet zwei bereits sortierte Eingaben in einem einzigen Durchlauf und ist ideal, wenn beide Seiten ohnehin ueber einen Index in der richtigen Reihenfolge vorliegen oder die Sortierung fuer eine ORDER-BY-Klausel ohnehin noetig ist.

Wichtig beim Lesen des EXPLAIN-Plans ist, welche Tabelle als aeussere und welche als innere Tabelle gewaehlt wird. Der Optimizer trifft diese Entscheidung anhand geschaetzter Zeilenzahlen, und eine falsche Schaetzung fuehrt haeufig zu einer suboptimalen Join-Reihenfolge. Bei mehr als drei beteiligten Tabellen waechst die Zahl moeglicher Join-Reihenfolgen exponentiell, weshalb Optimizer hier oft auf Heuristiken statt vollstaendiger Kostenberechnung zurueckgreifen.

-- MySQL: EXPLAIN FORMAT=JSON exposes join strategy explicitly
EXPLAIN FORMAT=JSON
SELECT p.product_name, SUM(oi.quantity) AS total_qty
FROM order_items oi
JOIN products p ON p.product_id = oi.product_id
WHERE oi.order_date >= '2026-06-01'
GROUP BY p.product_name;

-- Relevant excerpt of the JSON tree
-- "nested_loop": [
--   { "table": { "table_name": "oi", "access_type": "range",
--                "key": "idx_order_date", "rows_examined_per_scan": 4200 } },
--   { "table": { "table_name": "p", "access_type": "eq_ref",
--                "key": "PRIMARY", "rows_examined_per_scan": 1 } }
-- ]
-- Read as: oi is the outer (driving) table, p is probed once per row via PRIMARY KEY

5. Kostenmodelle und Kardinalitaetsschaetzungen verstehen

Das Kostenmodell hinter jedem EXPLAIN-Plan basiert auf zwei Bausteinen: geschaetzten Kosten pro Operation, etwa Seiten lesen oder Zeilen vergleichen, und geschaetzten Zeilenzahlen, der Kardinalitaet. Die Kardinalitaetsschaetzung stuetzt sich auf Tabellenstatistiken, Histogramme und Annahmen ueber Unabhaengigkeit von Spalten. Sind diese Statistiken veraltet, etwa nach einem grossen Bulk-Import ohne anschliessendes ANALYZE, trifft der Optimizer systematisch falsche Annahmen, und der resultierende EXPLAIN-Plan wirkt zwar plausibel, fuehrt aber zu einer schlechten tatsaechlichen Ausfuehrung.

Eine besonders haeufige Fehlerquelle ist die Annahme statistischer Unabhaengigkeit zwischen Spalten. Filtert eine Abfrage gleichzeitig nach Land und Stadt, geht der Optimizer typischerweise davon aus, dass beide Bedingungen unabhaengig selektiv sind und multipliziert ihre Selektivitaeten. Tatsaechlich korrelieren Land und Stadt aber stark, eine Stadt gehoert immer zu genau einem Land, wodurch die tatsaechliche Zeilenzahl deutlich von der Schaetzung im EXPLAIN-Plan abweichen kann. Moderne Datenbanken bieten dafuer erweiterte Statistiken auf mehreren Spalten gleichzeitig, etwa CREATE STATISTICS in PostgreSQL.

Ein grosser Unterschied zwischen geschaetzten und tatsaechlichen Zeilenzahlen im EXPLAIN-Plan ist eines der zuverlaessigsten Warnsignale ueberhaupt. Weicht die Schaetzung um mehr als eine Groessenordnung von der Realitaet ab, sollte man zuerst die Statistiken aktualisieren, bevor man ueber Indexaenderungen oder Query-Umschreibungen nachdenkt. Viele vermeintliche Performance-Probleme loesen sich bereits durch ein simples ANALYZE TABLE oder UPDATE STATISTICS.

6. Geschaetzter Plan vs. tatsaechliche Ausfuehrung mit ANALYZE

Ein reines EXPLAIN zeigt nur die geschaetzten Werte, ohne die Abfrage tatsaechlich auszufuehren. Fuer die Fehlersuche ist der Vergleich mit den tatsaechlichen Werten unverzichtbar. In PostgreSQL liefert EXPLAIN ANALYZE genau diesen Vergleich, indem die Abfrage wirklich laeuft und zusaetzlich zu den geschaetzten Werten auch die gemessene Zeit und Zeilenzahl pro Knoten im EXPLAIN-Plan ausgegeben wird. In MySQL erreicht man dasselbe mit EXPLAIN ANALYZE seit Version 8.0.18, in SQL Server mit "SET STATISTICS PROFILE ON" oder dem grafischen "Actual Execution Plan".

Der entscheidende Vorteil: Weicht die geschaetzte Zeilenzahl stark von der tatsaechlichen ab, ist das der zuverlaessigste Indikator fuer ein Statistik-Problem im EXPLAIN-Plan. Ein Knoten, der 50 Zeilen erwartet, aber 500.000 tatsaechlich liefert, erklaert oft allein, warum der Optimizer eine ungeeignete Join-Strategie gewaehlt hat, etwa einen Nested Loop dort, wo ein Hash Join deutlich effizienter gewesen waere. EXPLAIN ANALYZE fuehrt die Abfrage jedoch wirklich aus, bei schreibenden Statements oder sehr teuren Abfragen sollte man das in Produktionsumgebungen mit Bedacht einsetzen, in PostgreSQL kann die Kombination mit EXPLAIN (ANALYZE, BUFFERS) zusaetzlich zeigen, wie viele Seiten aus dem Cache oder von der Platte gelesen wurden.

Eine bewaehrte Vorgehensweise ist, den EXPLAIN-Plan zunaechst ohne ANALYZE zu pruefen, um grobe strukturelle Probleme wie fehlende Indizes zu erkennen, und erst danach mit ANALYZE die tatsaechliche Ausfuehrung zu messen, um die Wirkung einer Aenderung zu verifizieren. Dieser zweistufige Ansatz vermeidet unnoetige Last auf produktiven Systemen, waehrend man trotzdem belastbare Messwerte erhaelt.

-- PostgreSQL: compare estimated vs. actual rows and timing
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.order_id, o.total_amount
FROM orders o
WHERE o.status = 'shipped'
  AND o.order_date >= CURRENT_DATE - INTERVAL '30 days';

-- Sample output line to read carefully:
-- Index Scan using idx_orders_status (cost=0.42..120.31 rows=50 width=16)
--   (actual time=0.05..12.40 rows=48500 loops=1)
--   Buffers: shared hit=210 read=1840
-- rows=50 estimated vs. rows=48500 actual: statistics are stale, refresh them

7. Typische Red Flags im EXPLAIN-Plan erkennen

Bestimmte Muster tauchen in einem problematischen EXPLAIN-Plan immer wieder auf und lassen sich schnell erkennen, sobald man weiss, wonach man sucht. Ein Full Table Scan oder Seq Scan auf einer grossen Tabelle mit einer selektiven Filterbedingung ist das offensichtlichste Signal fuer einen fehlenden oder unpassenden Index. Ebenso verdaechtig ist eine grosse Diskrepanz zwischen geschaetzter und tatsaechlicher Zeilenzahl, wie im vorherigen Abschnitt beschrieben, denn sie fuehrt fast immer zu falschen Folgeentscheidungen des Optimizers weiter oben im Baum.

Ein weiteres Warnsignal im EXPLAIN-Plan ist ein "Sort"-Knoten, der grosse Datenmengen im Arbeitsspeicher oder, schlimmer, auf Platte sortieren muss, sichtbar in PostgreSQL an "Sort Method: external merge Disk". Das deutet darauf hin, dass entweder work_mem zu klein konfiguriert ist oder ein passender Index die Sortierung haette uebernehmen koennen, ohne dass ein eigener Sortierschritt noetig gewesen waere. Auch implizite Typumwandlungen, sichtbar an einem "Filter" statt einem "Index Cond" auf einer eigentlich indizierten Spalte, verhindern oft die Indexnutzung vollstaendig, weil eine Funktion oder ein Typkonflikt auf der Spalte angewendet wird.

Schliesslich lohnt der Blick auf wiederholte Ausfuehrungen desselben Teilbaums, etwa bei korrelierten Subqueries, die im EXPLAIN-Plan als "loops" mit hoher Anzahl erscheinen. Ein Knoten mit "loops=50000" bedeutet, dass diese Operation fuenfzigtausend Mal ausgefuehrt wurde, selbst eine an sich guenstige Einzeloperation summiert sich dann zu erheblicher Gesamtlaufzeit. Solche Muster sind haeufig ein Kandidat fuer eine Umformulierung als Join statt als korrelierte Subquery.

-- Red flag: correlated subquery re-executed once per outer row
SELECT o.order_id,
  (SELECT COUNT(*) FROM order_items oi WHERE oi.order_id = o.order_id) AS item_count
FROM orders o
WHERE o.status = 'pending';
-- EXPLAIN shows loops equal to the number of matching orders

-- Rewritten as a JOIN: the subquery runs once, not once per row
SELECT o.order_id, COUNT(oi.order_item_id) AS item_count
FROM orders o
LEFT JOIN order_items oi ON oi.order_id = o.order_id
WHERE o.status = 'pending'
GROUP BY o.order_id;

8. Werkzeuge zur Plan-Visualisierung

Der rohe Text-Output eines EXPLAIN-Plans ist bei komplexen Abfragen mit vielen Joins schwer zu ueberblicken, weshalb sich grafische Werkzeuge fuer die taegliche Arbeit bewaehrt haben. Fuer PostgreSQL hat sich das kostenlose Web-Tool explain.depesz.com etabliert, das den Plan farblich nach exklusiver Zeit pro Knoten einfaerbt und so sofort zeigt, welcher Knoten die meiste Zeit verbraucht. Alternativ visualisiert explain.dalibo.com den Plan als Baum-Diagramm mit Breite proportional zur Zeilenzahl.

MySQL Workbench bietet eine eingebaute Visual Explain-Ansicht, die den EXPLAIN-Plan als Diagramm mit Icons pro Operationstyp darstellt und Kosten sowie Zeilenzahlen direkt an den Knoten anzeigt. SQL Server Management Studio geht noch einen Schritt weiter mit dem "Actual Execution Plan", der nach Ausfuehrung prozentuale Kostenanteile pro Operator anzeigt und teure Knoten optisch durch dickere Pfeile hervorhebt, ein sehr intuitiver Weg, um auf einen Blick den teuersten Teil einer Abfrage zu finden.

Unabhaengig vom gewaehlten Tool gilt: Die Visualisierung ersetzt nicht das Verstaendnis der zugrunde liegenden Konzepte. Ein Tool zeigt lediglich denselben EXPLAIN-Plan in einer besser lesbaren Form, die Interpretation von Scan-Typen, Join-Strategien und Kostenschaetzungen bleibt dieselbe Aufgabe wie beim Lesen des reinen Textformats. Fuer Code-Reviews und Dokumentation empfiehlt es sich trotzdem, den Plan als Text mit einzuchecken, weil grafische Darstellungen selten versionierbar sind.

9. EXPLAIN-Syntax im Datenbankvergleich

Die konkrete Syntax zum Abrufen eines EXPLAIN-Plans unterscheidet sich zwischen den Datenbanksystemen, das zugrunde liegende Konzept jedoch nicht. Die folgende Tabelle stellt die wichtigsten Befehle und ihre Besonderheiten gegenueber, als schnelle Referenz beim Wechsel zwischen Systemen.

Trotz dieser syntaktischen Unterschiede bleibt die Leseweise eines EXPLAIN-Plans uebertragbar: Man sucht nach dem teuersten Knoten, prueft den Scan-Typ an den Blaettern, kontrolliert die Join-Strategie an den inneren Knoten und vergleicht, wo moeglich, geschaetzte mit tatsaechlichen Werten. Wer dieses mentale Modell einmal verinnerlicht hat, liest sich in ein neues Datenbanksystem binnen weniger Stunden ein, statt bei null anzufangen.

10. Zusammenfassung

Ein EXPLAIN-Plan ist im Kern immer dasselbe Konstrukt, ein Baum aus Operationen mit geschaetzten Kosten und Zeilenzahlen, unabhaengig davon, ob er von MySQL, PostgreSQL, SQL Server oder einer anderen relationalen Datenbank stammt. Scan-Typen zeigen, wie effizient einzelne Tabellen gelesen werden, Join-Strategien zeigen, wie Tabellen kombiniert werden, und der Vergleich zwischen geschaetzten und tatsaechlichen Werten deckt veraltete Statistiken auf. Wer diese drei Ebenen systematisch prueft, findet die Ursache einer langsamen Abfrage meist innerhalb weniger Minuten.

Der groesste Hebel liegt darin, den EXPLAIN-Plan nicht erst dann zu lesen, wenn eine Abfrage bereits Probleme bereitet, sondern ihn routinemaessig bei neuen, performancekritischen Abfragen zu pruefen. Ein kurzer Blick auf Full Table Scans, unerwartete Sort-Knoten und grobe Kardinalitaetsabweichungen verhindert viele Probleme, bevor sie in Produktion auffallen. Die Investition in dieses Grundverstaendnis zahlt sich bei jedem zukuenftigen Datenbanksystem erneut aus, weil das Konzept, anders als die Syntax, universell bleibt.

11. FAQ: EXPLAIN-Plaene lesen lernen