Stell dir vor, du entwickelst eine App und plötzlich wird einer deiner Queries zum teuersten in deiner Datenbank. Du bemerkst Aussetzer und die App wird langsam. Genau hier kommt EXPLAIN ins Spiel – es hilft dir zu checken, wo es hakt. Die Optimierung von Queries auf Basis der EXPLAIN-Analyse spart Ressourcen, Zeit und sorgt für ein besseres Nutzererlebnis.
EXPLAIN ist quasi dein Blick ins Innere von PostgreSQL: Du siehst, wie genau die Datenbank deinen Query ausführen will. Wird ein Index genutzt oder läuft alles auf einen Full Table Scan hinaus? Welche Schritte macht der Optimizer, in welcher Reihenfolge und wie groß werden die Zwischenergebnisse?
Mit anderen Worten: EXPLAIN zeigt dir, was dich beim Ausführen des Queries erwartet – wie „schwer“ er ist, wie viele Zeilen verarbeitet werden sollen und welche Ressourcen dabei draufgehen. Das ist ein unverzichtbares Tool, wenn ein Query plötzlich langsam wird und du wissen willst, warum.
EXPLAIN ist wie eine Taschenlampe im Dunkeln: Du siehst, was unter der Haube passiert und wo genau es schief läuft.
Syntax vom EXPLAIN-Befehl
Schauen wir uns die grundlegende Syntax von EXPLAIN an:
EXPLAIN dein_SQL_Query;
Beispiel-Query:
EXPLAIN SELECT * FROM students WHERE age > 20;
Wenn du diesen Befehl ausführst, führt PostgreSQL den Query nicht wirklich aus. Stattdessen bekommst du den Ausführungsplan. Das ist wie eine Skizze vor dem Bauen – praktisch, um zu sehen, was passieren wird, bevor du was kaputt machst.
Hier ein Beispiel für die Ausgabe:
Seq Scan on students (cost=0.00..35.00 rows=7 width=37)
Filter: (age > 20)
Das sieht erstmal abschreckend aus, aber keine Panik – wir gehen gleich die wichtigsten Teile durch.
Analyse eines einfachen Ausführungsplans
Schauen wir uns das Ergebnis mal genauer an:
Seq Scan on students – Das heißt, PostgreSQL scannt die Tabelle
studentskomplett (also ein sequentieller Scan). Das ist nicht immer schlimm, aber bei großen Tabellen kannSeq Scanlangsam sein.cost=0.00..35.00 – Das ist die Schätzung der Kosten für die Operation:
Startup Cost: Startkosten der Operation (hier0.00).Total Cost: Gesamtkosten bis zum Abschluss (hier35.00).
rows=7 – PostgreSQL schätzt, dass die Bedingung
age > 207 Zeilen zurückgibt. Das nennt man „Kardinalität“ (cardinality). Wenn die Schätzungen komisch aussehen, könnte die Statistik deiner Tabelle veraltet sein.width=37 – Das ist die durchschnittliche Größe einer Zeile in Bytes.
Filter: (age > 20) – PostgreSQL prüft für jede Zeile, ob sie die Bedingung erfüllt.
So gibt dir die EXPLAIN-Ausgabe einen Einblick in die Strategien und Annahmen von PostgreSQL. Diese Infos kannst du zur Optimierung nutzen.
Optionen für EXPLAIN
Auch wenn die Standardausgabe von EXPLAIN schon hilfreich ist, kannst du sie mit folgenden Optionen anpassen:
ANALYZE
Mit dieser Option zeigt dir PostgreSQL nicht nur den Plan, sondern führt den Query auch wirklich aus und liefert echte Daten. Beispiel:
EXPLAIN ANALYZE SELECT * FROM students WHERE age > 20;
So kannst du die Schätzungen von PostgreSQL mit der echten Ausführung vergleichen und sehen, wie gut sie passen.
VERBOSE
Zeigt noch mehr Details – praktisch für tiefergehende Analysen. Beispiel:
EXPLAIN VERBOSE SELECT * FROM students WHERE age > 20;
BUFFERS
Zeigt, wie viele Speicherpuffer beim Ausführen des Queries genutzt werden. Wird zusammen mit ANALYZE verwendet:
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM students WHERE age > 20;
COSTS
Wenn du die Kosteninfos (cost) ausblenden oder anzeigen willst, nimm diese Option:
EXPLAIN (COSTS OFF) SELECT * FROM students WHERE age > 20;
FORMAT
Der Plan kann auch in anderen Formaten wie JSON oder XML ausgegeben werden. Beispiel:
EXPLAIN (FORMAT JSON) SELECT * FROM students WHERE age > 20;
Beispiel für die Nutzung von EXPLAIN
Stell dir vor, du hast eine Datenbank university mit einer Tabelle students. Du willst alle Studierenden finden, die älter als 20 sind:
EXPLAIN SELECT * FROM students WHERE age > 20;
Die Ausgabe könnte so aussehen:
Seq Scan on students (cost=0.00..35.00 rows=7 width=37)
Filter: (age > 20)
Wie schon erwähnt, ist das ein sequentieller Scan (Seq Scan), der bei großen Tabellen nicht effizient ist.
Jetzt legen wir einen Index auf die Spalte age an und schauen, ob sich der Plan ändert:
CREATE INDEX age_index ON students(age);
EXPLAIN SELECT * FROM students WHERE age > 20;
Die Ausgabe:
Index Scan using age_index on students (cost=0.15..4.23 rows=7 width=37)
Index Cond: (age > 20)
Jetzt nutzt PostgreSQL einen Index Scan (Index Scan), was meistens schneller ist – vor allem bei großen Tabellen.
Typische Fragen und Fehler
Warum ist mein Query langsam, obwohl ich einen Index habe?
Vielleicht gibt dein Query zu viele Zeilen zurück, sodass der Index nicht viel bringt. Oder der Index ist nicht optimal oder veraltet.
Was, wenn ich die EXPLAIN-Ausgabe nicht verstehe?
Starte mit einfachen Queries und schau dir die Knoten im Ausführungsplan Schritt für Schritt an.
Wie finde ich raus, ob die Statistik der Tabelle veraltet ist?
Führe den Befehl ANALYZE students aus.
Wann sollte ich EXPLAIN ohne ANALYZE nutzen?
Wenn du nur den Plan sehen willst, ohne den Query wirklich auszuführen (z.B. bei Queries, die Daten verändern).
GO TO FULL VERSION