Was ist ein Ausführungsplan in SQL?

Wie der Optimizer zu einem Plan kommt

SQL ist deklarativ: Du schreibst, welche Zeilen du haben willst, nicht wie die Datenbank sie findet. Für eine Abfrage mit drei verbundenen Tabellen gibt es Dutzende mögliche Wege, etwa unterschiedliche Join-Reihenfolgen, Indexzugriffe oder vollständige Durchläufe. Der Optimizer schätzt für jede sinnvolle Variante die Kosten und nimmt die günstigste.

Grundlage dieser Schätzung sind Statistiken über die Daten: wie viele Zeilen eine Tabelle hat, wie viele verschiedene Werte eine Spalte enthält und wie sie verteilt sind. Fragst du zum Beispiel alle Bestellungen eines einzelnen Kunden ab, erwartet der Optimizer wenige Treffer und greift über den Index zu. Fragst du alle Bestellungen des letzten Jahres ab, liest er die Tabelle womöglich komplett, weil das bei vielen Treffern schneller ist.

Viele Datenbanken heben einmal berechnete Pläne auf. SQL Server und Oracle legen sie in einem Plan-Cache ab, PostgreSQL nutzt für Prepared Statements nach einigen Ausführungen unter Umständen einen generischen Plan. Das spart Rechenzeit, kann aber dazu führen, dass ein Plan, der für einen bestimmten Parameterwert gut war, bei einem anderen Wert schlecht passt.

So liest du den Plan

In PostgreSQL und MySQL stellst du EXPLAIN vor die Abfrage und bekommst den Plan als Baum. Gelesen wird er von innen nach außen: Die am weitesten eingerückten Knoten laufen zuerst und reichen ihre Zeilen nach oben weiter. Jeder Knoten trägt Startkosten, Gesamtkosten, erwartete Zeilenzahl und Zeilenbreite. Die Kosten sind eine dimensionslose Rechengröße, keine Millisekunden.

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM bestellungen WHERE kunde_id = 4711;

Mit ANALYZE wird die Abfrage tatsächlich ausgeführt, und jeder Knoten bekommt zusätzlich die gemessene Zeit und die echte Zeilenzahl. Vergleiche in jedem Knoten Schätzung und Wirklichkeit. Weichen sie um Größenordnungen voneinander ab, hat der Optimizer auf falscher Grundlage entschieden, und alle Entscheidungen weiter oben im Baum sind ebenfalls fragwürdig.

BUFFERS zeigt, wie viele Blöcke aus dem Cache und wie viele von der Platte kamen, ab PostgreSQL 18 ist diese Angabe bei EXPLAIN ANALYZE automatisch dabei. Eine Abfrage, die beim zweiten Aufruf schnell ist, war oft nicht optimiert, sondern nur warmgelaufen.

Weil EXPLAIN ANALYZE die Anweisung wirklich ausführt, gehört ein UPDATE oder DELETE dabei in eine Transaktion, die du anschließend mit ROLLBACK zurückrollst. Sonst analysierst du deine Daten nicht, sondern änderst sie.

Was die häufigsten Knoten bedeuten

Die Namen stammen aus PostgreSQL, in anderen Datenbanken heißen die Operatoren ähnlich (im SQL Server etwa Table Scan, Index Seek und Hash Match). Kein Knoten ist für sich gut oder schlecht, entscheidend ist, ob er zur Zeilenzahl passt.

Gefährlich wird ein Nested Loop, wenn der Optimizer zehn äußere Zeilen erwartet und es in Wahrheit hunderttausend sind. Achte außerdem auf Sort- und Hash-Knoten, die auf externen Speicher ausweichen: Reicht der Arbeitsspeicher nicht, schreibt die Datenbank Zwischenergebnisse auf die Platte, und das kostet mehr Zeit als jeder Indexzugriff.

Den Plan in anderen Datenbanken anzeigen

Das Prinzip ist überall gleich, nur die Befehle unterscheiden sich. Fast alle Systeme kennen einen geschätzten Plan, der nichts ausführt, und einen tatsächlichen Plan mit Messwerten.

Im SQL Server Management Studio erscheint der Plan grafisch, gelesen wird er dort von rechts nach links. Ein Ausrufezeichen am Operator weist auf eine Warnung hin, etwa eine fehlende Statistik oder eine implizite Typumwandlung, die einen Indexzugriff verhindert.