PostgreSQL EXPLAIN lesen, bevor Sie einen Index anlegen

Mit Schätzungen beginnen

Verwenden Sie zunächst EXPLAIN ohne ANALYZE, wenn die Ausführung teuer sein könnte. Plankosten sind keine Millisekunden. Ein sequenzieller Scan kann sinnvoll sein, wenn ein großer Teil einer kleinen Tabelle benötigt wird.

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

In geeigneter Umgebung messen

Prüfen Sie bei einem sicheren SELECT Zeilen, loops und Pufferzugriffe. Große Schätzfehler sprechen für eine Prüfung von Statistik und Datenverteilung. ANALYZE führt auch Schreiboperationen aus; verwenden Sie es dort nicht unbedacht.

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

Zuerst eine einzelne Planzeile lesen

Der Ausschnitt unten ist ein Beispiel, keine Messung einer echten Datenbank. cost=0.43..8.61 beschreibt geschätzte Start- und Gesamtkosten in Planereinheiten. rows=10 erwartet zehn Ausgabezeilen; width=16 schätzt ihre mittlere Größe in Bytes.

Der gemessene Teil würde 10.000 statt zehn Zeilen bei einer Ausführung zeigen. actual time=0.05..12.00 nennt die Zeit bis zur ersten Zeile und bis zum Abschluss in Millisekunden. Die große Mengenabweichung spricht dafür, zuerst die Schätzung zu untersuchen, statt unmittelbar ein weiteres Indexproblem anzunehmen.

Index Scan using orders_customer_idx on orders
  (cost=0.43..8.61 rows=10 width=16)
  (actual time=0.05..12.00 rows=10000 loops=1)

Von den Blättern aus wiederholte Arbeit erkennen

Einrückung zeigt, welche Knoten ihre Eltern beliefern. Ein Scan liefert Daten für Join, Sortierung oder Aggregat. Suchen Sie wachsenden Aufwand: viele verworfene Zeilen, umfangreiche Sortierung oder häufig wiederholte innere Operationen.

Bei gewöhnlichen Knoten sind tatsächliche Zeilen und Zeiten Mittelwerte je Ausführung. actual rows=5 und loops=1000 ergeben ungefähr 5.000 Ausgabezeilen insgesamt. Zeiten können die Arbeit der Kinder einschließen; ihre Addition zählt Aufwand doppelt. Parallele Pläne erfordern weitere Einordnung. Execution Time ist ein Bezugspunkt für die gesamte Dauer.

Mit Puffern und Statistiken genauer untersuchen

BUFFERS ergänzt Zeitmessungen durch Datenzugriffe. shared hit bedeutet einen Fund im gemeinsamen PostgreSQL-Puffer; shared read ein Einlesen dorthin, möglicherweise aus dem Betriebssystemcache. Gezählt werden Zugriffe, nicht zwingend unterschiedliche Blöcke oder physische Plattenzugriffe.

Veraltete Statistiken oder ungleich verteilte Werte können Schätzfehler verursachen. ANALYZE orders sammelt Tabellenstatistiken und unterscheidet sich von EXPLAIN ANALYZE, das die Abfrage ausführt. Prüfen Sie nach umfangreichen Änderungen die Statistiken. Eine auf Platte ausgelagerte Sortierung braucht eine andere Untersuchung als ein falsch geschätzter Join.

ANALYZE orders;

Eine Änderung mit vergleichbaren Daten bewerten

Formulieren Sie eine Vermutung: zu viele unnötige Zeilen, wiederholte Suchen oder ein großes sortiertes Zwischenergebnis. Ein selektiver Filter kann von einem passenden Index profitieren. Für kleine Tabellen oder viele Ergebniszeilen kann ein sequenzieller Scan sinnvoll bleiben.

Vergleichen Sie gleiche Parameter und Daten. Wiederholen Sie Messungen, da Cache und gleichzeitige Last die Dauer beeinflussen. Ein einzelner schneller, aufgewärmter Lauf belegt keine allgemeine Verbesserung. Berücksichtigen Sie Speicher und Schreibaufwand des Index. Beginnen Sie mit einem geeigneten SELECT: EXPLAIN ANALYZE führt auch Änderungen aus und kann Nebenwirkungen haben.