Postgres EXPLAIN ANALYZE: Abfragen verstehen und optimieren

Veröffentlicht

1. September 2026

Autor

Faizan Nadeem

Was EXPLAIN ANALYZE tatsächlich macht

EXPLAIN allein fragt den Planer, was er tun würde — er schätzt anhand von Tabellenstatistiken einen Plan und gibt ihn aus, ohne etwas auszuführen. EXPLAIN ANALYZE führt die Abfrage tatsächlich aus, misst jeden Schritt zeitlich und gibt dann denselben Baum mit Anmerkungen dazu aus, was wirklich passiert ist. Dieser Unterschied ist wichtiger, als es klingt: EXPLAIN kann man gefahrlos gegen alles ausführen, auch gegen ein DROP, das in einer Transaktion steckt, die man zurückrollen will, aber EXPLAIN ANALYZE führt ein INSERT, UPDATE oder DELETE wirklich aus, sofern man es nicht in BEGIN; ... ROLLBACK; einbettet.

Die Ausgabe, die du für echtes Debugging tatsächlich willst, hat diese Form:

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.id, o.total, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > now() - interval '7 days'
  AND o.status = 'pending';

ANALYZE liefert dir reale Laufzeiten und reale Zeilenanzahlen. BUFFERS liefert dir Informationen zu Cache-Treffern, was aus historischen Gründen standardmäßig deaktiviert ist, aber in jeder echten Untersuchung wirklich nützlich ist — schalte es jedes Mal ein. Lass COSTS OFF weg, außer du fügst den Plan irgendwo ein, wo er über mehrere Läufe hinweg diffbar sein muss; du willst die Kostenschätzungen für den Vergleich mit den tatsächlichen Werten.

Ein Plan ist ein Baum, gelesen von unten nach oben und von innen nach außen. Die innersten, am stärksten eingerückten Knoten laufen zuerst; ihre Ausgabe fließt in den direkt darüberliegenden Knoten. Die oberste Zeile ist das Letzte, was passiert, und dort werden Gesamtzeit und Gesamtkosten gemeldet. Es ist verlockend, ihn wie Fließtext von oben nach unten zu lesen, aber der eigentliche Datenfluss — und meist auch der eigentliche Flaschenhals — steckt in den Blättern ganz unten.

Anatomie einer Planzeile

Hier ist ein einzelner Knoten aus einem echten Plan, Stück für Stück erläutert:

Seq Scan on orders o  (cost=0.00..18734.00 rows=812 width=24)
                       (actual time=0.021..142.558 rows=790 loops=1)
  Filter: (status = 'pending'::text)
  Rows Removed by Filter: 199210
  Buffers: shared hit=210 read=8312

Aufgeschlüsselt bedeutet das:

Seq Scan on orders o — die Operation und die Tabelle (oder ihr Alias), auf der sie ausgeführt wird. Ein Sequential Scan liest jede Zeile der Tabelle oder des Index in physischer Reihenfolge; das ist nicht automatisch schlecht, aber bei einer großen Tabelle genau das, worauf man achten sollte.
cost=0.00..18734.00 — der geschätzte Kostenbereich des Planers, in beliebigen planer-internen Kosteneinheiten (nicht Millisekunden). Die erste Zahl ist die geschätzte Kostenmenge, um die erste Zeile zurückzugeben; die zweite ist die geschätzte Kostenmenge, um alle Zeilen zurückzugeben. Diese Zahlen sind nur mit anderen Kostenwerten im selben Plan vergleichbar, niemals zwischen Abfragen oder Servern.
rows=812 — die Schätzung des Planers, wie viele Zeilen dieser Knoten erzeugen wird, basierend auf Tabellenstatistiken.
width=24 — die geschätzte durchschnittliche Zeilenbreite in Bytes.
actual time=0.021..142.558 — echte, gemessene Millisekunden: Zeit bis zur ersten Zeile und dann Zeit bis zum Abschluss, gemittelt über alle Schleifendurchläufe hinweg (mehr dazu gleich).
rows=790 loops=1 — die reale Anzahl an Zeilen, die dieser Knoten tatsächlich zurückgegeben hat, und wie oft der Knoten ausgeführt wurde.
Filter / Rows Removed by Filter — ein Filter nach dem Scan, der angewendet wird, nachdem die Zeilen geholt wurden. Eine große Zahl bei „rows removed“ neben einer kleinen finalen Zeilenanzahl ist ein starkes Signal, dass der Scan viel mehr Arbeit macht als nötig.
Buffers — wie viele 8KB-Seiten berührt wurden, aufgeteilt in Cache-Treffer und Disk-Lesevorgänge.

Jeder Knoten im Baum hat diese gleiche Form. Sobald du eine Zeile parsen kannst, kannst du den ganzen Plan lesen — die Fähigkeit besteht vollständig darin zu wissen, welche Zahlen man miteinander vergleichen muss.

Geschätzte vs. tatsächliche Zeilen

Das ist der Vergleich mit dem höchsten Nutzen im gesamten Plan. Der Planer schätzt rows=812, bevor irgendetwas ausgeführt wird, basierend auf Statistiken, die durch ANALYZE gesammelt wurden (den Wartungsbefehl, nicht die EXPLAIN-Option — verwirrenderweise haben sie denselben Namen). Nach der Ausführung meldet Postgres, was tatsächlich herauskam. Wenn diese beiden Zahlen nah beieinanderliegen, hatte der Planer gute Informationen und hat mit hoher Wahrscheinlichkeit einen guten Plan gewählt. Wenn sie um den Faktor 10, 100 oder mehr danebenliegen, dann wurde alles, was auf dieser Schätzung aufbaut — Join-Strategie, Speicherzuweisung, Ausführungsreihenfolge — mit schlechten Informationen entschieden, und der resultierende Plan ist oft auf eine Weise schlecht, die sich allein aus der Schätzung kaum vorhersagen lässt.

-> Index Scan using idx_orders_status on orders
     (cost=0.42..8.44 rows=1 width=24)
     (actual rows=48000 loops=1)

Eine Schätzung von 1 Zeile gegenüber tatsächlich 48.000 ist eine massive Fehleinschätzung. Das passiert normalerweise aus einem von wenigen Gründen:

Veraltete Statistiken. Die Tabelle hat sich seit dem letzten ANALYZE deutlich verändert, und autovacuum ist noch nicht nachgekommen. Führe ANALYZE orders; manuell aus und vergleiche.
Korrelierte Spalten. Der Planer nimmt standardmäßig an, dass Spalten unabhängig sind. Ein Filter wie WHERE status = 'pending' AND created_at > now() - interval '7 days' kann in Kombination deutlich selektiver (oder weniger selektiv) sein als jede Spalte für sich, und die Standardstatistiken erfassen diese Korrelation nicht. Postgres-CREATE STATISTICS für erweiterte Statistiken existiert genau, um das zu beheben.
Ungleichmäßige Datenverteilung. Wenn 90 % der Zeilen denselben Wert in einer schief verteilten Spalte teilen, kann das Standardziel für Statistiken (standardmäßig 100 Buckets) diese Schiefe möglicherweise nicht fein genug auflösen. Das Erhöhen von default_statistics_target oder das Setzen pro Spalte mit ALTER TABLE ... ALTER COLUMN ... SET STATISTICS gibt dem Planer ein feineres Histogramm.

Wenn du allgemeines Debugging langsamer Postgres-Abfragen machst, ist dieser Vergleich der erste Ort, auf den du schauen solltest, noch vor Buffers, noch vor Kostenzahlen, noch vor allem anderen — eine schlechte Schätzung ist meist die eigentliche Ursache, und alles danach ist nur ein Symptom.

Loops: Warum ein billiger Knoten dominieren kann

loops=1 bedeutet, dass der Knoten einmal ausgeführt wurde. Unter einem Nested-Loop-Join kann ein innerer Knoten einmal pro Zeile ausgeführt werden, die von der äußeren Seite produziert wird — und die angegebene actual time für diesen Knoten ist der Durchschnitt pro Schleife, nicht die Gesamtsumme. Das ist die häufigste Fehlinterpretation im gesamten Plan.

Nested Loop  (actual time=0.045..891.223 rows=48000 loops=1)
  -> Seq Scan on customers c (actual time=0.010..12.400 rows=4000 loops=1)
  -> Index Scan using idx_orders_customer on orders o
       (actual time=0.008..0.019 rows=12 loops=4000)

Dieser innere Index Scan sieht trivial billig aus: 0.019ms. Aber er lief 4.000 Mal — einmal pro Kundenzeile aus dem äußeren Scan — also ist sein tatsächlicher Beitrag grob 0.019ms * 4000 ≈ 76ms, nicht 0.019ms. Multipliziere die tatsächliche Zeit immer mit der Schleifenanzahl, bevor du die echten Kosten eines Knotens beurteilst. Eine winzige Zeit pro Schleife bei einer fünfstelligen Schleifenanzahl ist oft der eigentliche Flaschenhals, der sich offen versteckt, während der Knoten mit der einzelnen größten actual time vergleichsweise wenig beiträgt.

Das ist auch der Mechanismus hinter dem klassischen Bug „funktioniert mit 100 Zeilen gut, kippt bei 100.000 um“: Ein Nested Loop ist eine gute Strategie, wenn die äußere Seite klein ist, und eine sich linear verschlechternde, wenn sie wächst — genau die Form des N+1-Problems, das auch auf ORM-Ebene auftaucht. Sieh dir dazu den Django N+1-Beitrag an, um dieses Muster aus Sicht der Anwendung zu sehen.

Buffers lesen: Cache-Treffer vs. Disk-Lesevorgänge

Buffers: shared hit=210 read=8312 meldet 8KB-Seitenzugriffe auf den Shared-Buffer-Cache:

shared hit — Seiten, die bereits im Shared-Buffer-Cache von PostgreSQL gefunden wurden. Schnell; praktisch RAM-Geschwindigkeit.
shared read — Seiten, die von Disk geholt werden mussten (oder aus dem OS-Page-Cache, was Postgres nicht von echtem Disk-I/O unterscheiden kann), weil sie nicht im Buffer-Cache lagen.
shared dirtied — Seiten, die in dieser Operation verändert wurden, relevant bei Schreibvorgängen.
shared written — Seiten, die hinausgeschrieben wurden, um Platz zu schaffen, oft ein Zeichen für Druck auf den Buffer-Cache.

Ein hoher read-Wert relativ zu hit bei einer häufig laufenden Abfrage signalisiert, dass das Working Set nicht bequem in shared_buffers passt — oder dass es sich einfach um einen kalten Cache bei einer selten ausgeführten Abfrage handelt. Führe dasselbe EXPLAIN (ANALYZE, BUFFERS) zweimal hintereinander aus; wenn der zweite Lauf überwiegend Treffer zeigt, wo der erste überwiegend Lesevorgänge zeigte, dann hast du Zahlen aus einem kalten Cache betrachtet und nicht die Kosten im eingeschwungenen Zustand.

Buffers sind außerdem das ehrlichste verfügbare Kostensignal, weil sie nicht durch beliebige planer-interne Kosteneinheiten skaliert sind — es sind buchstäbliche Seitenanzahlen, die sich direkt über verschiedene Abfragen und verschiedene Pläne derselben Abfrage hinweg vergleichen lassen. Wenn zwei mögliche Indizes Pläne mit ähnlicher actual time erzeugen, dann verrichtet der mit weniger gesamten Buffer-Zugriffen tatsächlich weniger I/O-Arbeit und hält unter paralleler Last besser stand.

Die drei Muster, die auf einen fehlenden Index hinweisen

Wenn man genug Pläne gesehen hat, tauchen drei Formen ständig wieder auf, und alle drei deuten auf dieselbe Grundursache hin.

1. Ein Sequential Scan mit einem selektiven Filter auf einer großen Tabelle.

Seq Scan on orders o  (cost=0.00..18734.00 rows=812 width=24)
                       (actual time=0.021..142.558 rows=790 loops=1)
  Filter: (status = 'pending'::text)
  Rows Removed by Filter: 199210

200.000 Zeilen zu scannen, um 790 davon zu behalten, bedeutet, dass der Plan fast seine gesamte Arbeit damit verbringt, Zeilen wegzuwerfen. Rows Removed by Filter, das um Größenordnungen über der finalen Zeilenanzahl liegt, auf einer Tabelle, die zu groß ist, um bequem in den Cache zu passen, ist die implizite Art von Postgres zu sagen: „Ich habe keinen Index, um direkt zu den gewünschten Zeilen zu springen.“ Ein Index auf status — oder besser ein partieller Index (WHERE status = 'pending'), wenn dieser Wert selten ist — verwandelt das in einen Index Scan, der nur die passenden Zeilen berührt.

2. Ein Nested Loop mit sehr hoher Schleifenanzahl, der einen unindizierten inneren Scan speist.

-> Seq Scan on order_items oi
     (actual time=0.412..3.891 rows=6 loops=4000)
   Filter: (order_id = o.id)

Ein innerer Sequential Scan, der tausende Male läuft und jedes Mal die gesamte Tabelle order_items auf eine Handvoll passender Zeilen herunterfiltert, ist das Schleifenmuster aus dem vorherigen Abschnitt kombiniert mit einem fehlenden Index auf der Join-Spalte. Ein Index auf order_items(order_id) verwandelt jeden dieser 4.000 Sequential Scans in einen billigen Index-Lookup, und die gesamte Abfragezeit sinkt meist um eine Größenordnung oder mehr.

3. Ein Sort, der auf Disk auslagert, statt im Speicher abgeschlossen zu werden.

Sort  (cost=41293.55..41808.36 rows=205925 width=32)
      (actual time=387.223..421.009 rows=205925 loops=1)
  Sort Method: external merge  Disk: 7128kB
  -> Seq Scan on orders ...

Sort Method: external merge Disk: ...kB bedeutet, dass der Sort nicht in work_mem gepasst hat und in temporäre Dateien auf Disk ausgelagert wurde — spürbar langsamer als ein In-Memory-Quicksort oder ein Top-N-Heapsort. Hier greifen zwei unabhängige Lösungen, und sie schließen sich nicht gegenseitig aus: Erhöhe work_mem für die Session oder die Abfrage, wenn der Server noch Spielraum hat, oder — meist die bessere Lösung — füge einen Index hinzu, der zur ORDER BY-Klausel passt, sodass der Sort vollständig vermieden wird und die Zeilen bereits vorsortiert aus einem Index Scan statt aus einem Sort-Knoten kommen.

Alle drei Muster teilen dieselbe zugrunde liegende Geschichte: Der Planer tut mit einer sequentiellen oder Brute-Force-Strategie das Beste, was er kann, weil kein besserer Pfad verfügbar ist. Für einen vollständigen Überblick, welcher Indextyp zu welcher dieser Formen passt — B-tree, GIN, GiST oder BRIN — behandelt der Leitfaden zu Postgres-Indextypen die Entscheidung ausführlich.

Eine vollständige Schritt-für-Schritt-Analyse

Nehmen wir einen tatsächlich langsamen Endpunkt: „Liste ausstehende Bestellungen der letzten Woche für das Konto eines Kunden auf, die neuesten zuerst.“ Die Abfrage:

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821
  AND status = 'pending'
  AND created_at > now() - interval '7 days'
ORDER BY created_at DESC
LIMIT 20;

Erster Plan, vor irgendwelchen Änderungen:

Limit  (actual time=203.441..203.448 rows=14 loops=1)
  -> Sort  (actual time=203.439..203.443 rows=14 loops=1)
        Sort Key: created_at DESC
        Sort Method: quicksort  Memory: 26kB
        -> Seq Scan on orders  (actual time=0.033..201.887 rows=14 loops=1)
              Filter: ((customer_id = 4821) AND (status = 'pending')
                       AND (created_at > now() - interval '7 days'))
              Rows Removed by Filter: 611982
              Buffers: shared hit=402 read=9812

So liest man ihn: Der Sort ist trivial (14 Zeilen, In-Memory-Quicksort). Der Seq Scan hat 611.982 Zeilen herausgefiltert, um 14 zu behalten, und dabei über 10.000 Buffer-Seiten berührt — Muster eins, eindeutig. Die Lösung ist ein zusammengesetzter Index, der zu den Filterspalten passt und den Sortierschlüssel einschließt, sodass die Datenbank potenziell auch einen separaten Sort-Schritt überspringen kann:

CREATE INDEX CONCURRENTLY idx_orders_customer_status_created
ON orders (customer_id, status, created_at DESC);

Wenn man dieselbe Abfrage nach dem Aufbau des Index erneut ausführt:

Limit  (actual time=0.061..0.089 rows=14 loops=1)
  -> Index Scan using idx_orders_customer_status_created on orders
        (actual time=0.060..0.086 rows=14 loops=1)
        Index Cond: ((customer_id = 4821) AND (status = 'pending')
                      AND (created_at > (now() - interval '7 days')))
        Buffers: shared hit=6

203ms runter auf 0.089ms, Buffer-Zugriffe von ~10.200 auf 6 reduziert und überhaupt kein Sort-Knoten mehr — die Spaltenreihenfolge des Index passt bereits zu den Anforderungen von LIMIT 20. Das ist der gesamte Diagnosezyklus: den Baum lesen, den Knoten mit dem größten realen Zeitbeitrag finden, seine Form einem der drei Muster zuordnen, den Index korrigieren und erneut ausführen, um zu bestätigen, dass sich die Planform tatsächlich geändert hat.

Häufige Fallstricke

Fehler: Kostenwerte zwischen verschiedenen Abfragen vergleichen. Kosten sind eine einheitslose, planer-interne Schätzung, kalibriert durch random_page_cost und ähnliche Parameter — sie sind nur relativ zu anderen Knoten im selben Plan sinnvoll. Lösung: Für Vergleiche zwischen Abfragen actual time und Buffer-Anzahlen vergleichen, nicht cost.

Fehler: actual time bei einem Schleifenknoten als Gesamtsumme lesen. Wie oben gezeigt, ist diese Zahl ein Durchschnitt pro Schleife. Lösung: Immer mit loops multiplizieren, bevor du den echten Beitrag eines Knotens beurteilst.

Fehler: EXPLAIN ANALYZE einmal auf einem kalten Cache ausführen und daraus schließen, dass die Abfrage in Produktion langsam ist. Der erste Lauf nach einem Neustart oder gegen selten berührte Daten zahlt Disk-I/O-Kosten, die der Normalbetrieb meist nicht hat. Lösung: Zweimal ausführen und dem Verhältnis der Buffer-Treffer vertrauen, nicht nur der ersten Zahl.

Fehler: annehmen, dass „index scan“ immer besser ist als „seq scan“. Auf einer kleinen Tabelle oder wenn eine Abfrage ohnehin die meisten Zeilen der Tabelle braucht, ist ein Sequential Scan tatsächlich schneller — ohne den Overhead des Index-Durchlaufs. Lösung: Nach tatsächlicher Zeit und Zeilenanzahl urteilen, nicht allein nach dem Knotennamen.

Fehler: einen Index hinzufügen und EXPLAIN ANALYZE nicht erneut ausführen, um zu bestätigen, dass sich der Plan tatsächlich geändert hat. Postgres verwendet einen neuen Index nicht zwingend, wenn seine Statistiken weiterhin den alten Plan bevorzugen oder wenn der Index nicht zur führenden Filterspalte der Abfrage passt. Lösung: Immer erneut ausführen und prüfen, dass sich die Planform geändert hat, nicht nur, dass die Abfrage schneller wurde — eine schnellere Laufzeit allein beweist nicht, dass die Korrektur verallgemeinerbar ist.

Wie es von hier aus weitergeht

Dieser Beitrag behandelt das Lesen eines einzelnen Plans in Isolation. Der Rest dieser Reihe behandelt die Entscheidungen, die überhaupt erst bestimmen, welche Pläne überhaupt möglich sind:

Den richtigen Indextyp wählen — B-tree, GIN, GiST und BRIN und bei welchen Abfrageformen jeder davon tatsächlich hilft.
N+1-Abfragen in Django finden und beseitigen — das Schleifenmuster aus diesem Beitrag, gesehen von der ORM-Seite statt von der Planseite.
Connection Pooling für Python-Apps — denn ein schneller Abfrageplan hilft nicht, wenn Requests auf eine Verbindung wartend in der Schlange stehen.
pgvector vs. eine dedizierte Vektor-Datenbank — das Lesen von Plänen für Ähnlichkeitssuche hat seine eigenen Eigenheiten, die man kennen sollte.
Postgres-Migrationen ohne Downtime — genau die Indizes aus diesem Beitrag bauen, ohne die Tabelle zu sperren, die man gerade beschleunigen will.

Zum Abschluss

Ein Postgres-Abfrageplan ist keine geheimnisvolle Ausgabe, die man nach furchteinflößenden Zahlen überfliegt — er ist ein strukturiertes, ehrliches Protokoll darüber, was die Datenbank genau getan hat, in welcher Reihenfolge und wie das im Vergleich zu ihren Erwartungen ausfiel. Lies ihn von unten nach oben, vergleiche zuerst geschätzte mit tatsächlichen Zeilen, multipliziere Schleifenknoten vor der Beurteilung ihrer Kosten mit ihrer Schleifenanzahl, prüfe das Verhältnis der Buffer-Treffer auf Cache-Druck und gleiche das Gesehene mit den drei Mustern ab, die bedeuten: „Der Planer hat hier keine gute Option.“ Sobald diese Leserichtung automatisch wird, ist EXPLAIN ANALYZE keine Textwand mehr, sondern das schnellste Debugging-Werkzeug im gesamten Stack.

Wenn eine Abfrage das nächste Mal langsam ist, kommt dein erster Schritt dann aus dem Plan oder aus einer Vermutung?