Mehrere CTEs verketten: Lesbarkeit vs. Performance-Realität

1. Grundprinzip: jede CTE baut auf der vorherigen auf

Eine WITH-Klausel kann mehrere durch Komma getrennte CTE-Definitionen enthalten, wobei jede nachfolgende CTE auf alle zuvor definierten CTEs zugreifen darf. Dadurch entsteht eine Kette von benannten Zwischenschritten, die jeweils für sich genommen einfach und nachvollziehbar bleiben, während die Gesamtkomplexität der Auswertung erst aus dem Zusammenspiel aller Schritte entsteht. Das unterscheidet sich grundlegend von einer tief verschachtelten Subquery, bei der der Leser von innen nach außen oder von außen nach innen denken muss, um die Logik zu verstehen.

Ein typisches Muster ist eine Kette aus drei bis fünf Schritten: zuerst eine CTE, die Rohdaten filtert und vorverarbeitet, dann eine CTE, die auf dieser Basis aggregiert, anschließend eine CTE, die Kennzahlen über Window Functions berechnet, und schließlich die eigentliche Hauptabfrage, die aus der letzten CTE das finale Ergebnis formt. Jeder einzelne Schritt lässt sich isoliert testen, indem man die WITH-Kette temporär durch ein einfaches SELECT auf die jeweilige Zwischen-CTE ersetzt.

WITH filtered_orders AS (
    SELECT customer_id, order_id, total_amount, order_date
    FROM orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '365 days'
      AND status = 'completed'
),
customer_totals AS (
    SELECT customer_id, COUNT(*) AS order_count, SUM(total_amount) AS total_spent
    FROM filtered_orders
    GROUP BY customer_id
),
ranked_customers AS (
    SELECT
        customer_id,
        order_count,
        total_spent,
        PERCENT_RANK() OVER (ORDER BY total_spent) AS spend_percentile
    FROM customer_totals
)
SELECT customer_id, order_count, total_spent, spend_percentile
FROM ranked_customers
WHERE spend_percentile >= 0.9
ORDER BY total_spent DESC;

2. Lesbarkeit durch sprechende Zwischennamen statt anonymer Subqueries

Der größte praktische Vorteil verketteter CTEs liegt in der Namensgebung: Jeder Zwischenschritt erhält einen eigenen, fachlich sprechenden Namen, der bereits vor dem Lesen des eigentlichen Codes vermittelt, welche Aufgabe dieser Schritt in der Gesamtlogik übernimmt. Eine anonyme, verschachtelte Subquery bietet diese Möglichkeit nicht, ihr Zweck muss aus dem Kontext und der Position innerhalb der äußeren Abfrage erschlossen werden, was bei mehreren Verschachtelungsebenen zunehmend mühsam wird.

Diese Namensgebung zahlt sich besonders bei Code-Reviews und bei der späteren Wartung durch andere Teammitglieder aus. Eine gut benannte CTE-Kette liest sich fast wie eine dokumentierte Schrittfolge, während eine tief verschachtelte Subquery-Konstruktion selbst für den ursprünglichen Autor nach einigen Monaten oft erst nach längerem Nachdenken wieder verständlich wird. Der Dokumentationswert einer klaren CTE-Kette sollte bei der Entscheidung für diesen Stil nicht unterschätzt werden.

3. Materialisierungsverhalten vor PostgreSQL 12

Bis einschließlich PostgreSQL 11 wurde jede CTE grundsätzlich als eigenständiges, materialisiertes Zwischenergebnis behandelt, unabhängig davon, wie sie in der äußeren Abfrage verwendet wurde. Das bedeutete, dass der Optimizer eine CTE wie eine Art temporäre Tabelle betrachtete: Filterbedingungen aus der äußeren Abfrage konnten nicht in die CTE hinein propagiert werden, und der Optimizer konnte die CTE-Definition nicht mit dem Rest der Abfrage gemeinsam optimieren.

Dieses Verhalten hatte einen praktischen Vorteil, der bewusst genutzt wurde: Eine CTE als sogenannte Optimization Fence, also als bewusste Optimierungsgrenze, ließ sich gezielt einsetzen, um den Optimizer zu einer bestimmten Ausführungsreihenfolge zu zwingen, wenn eine automatische Umformulierung durch den Optimizer aus Erfahrung zu einem schlechteren Plan geführt hätte. Der Nachteil war, dass dieselbe Materialisierung auch dann erzwungen wurde, wenn sie fachlich gar nicht nötig gewesen wäre, was bei großen Zwischenergebnissen unnötig Arbeitsspeicher und Zeit kostete.

4. Das Umdenken seit PostgreSQL 12: Inlining als Standardverhalten

Seit PostgreSQL 12 hat sich das Standardverhalten grundlegend geändert: Eine CTE wird nun, sofern möglich, automatisch in die umgebende Abfrage eingebettet, ähnlich wie eine Subquery, statt zwingend materialisiert zu werden. Das erlaubt dem Optimizer, Filterbedingungen aus der äußeren Abfrage in die CTE hinein zu verschieben, Indizes über CTE-Grenzen hinweg zu nutzen, und insgesamt einen globalen Ausführungsplan für die gesamte Kette zu erstellen, was in vielen Fällen zu einer deutlich besseren Performance führt als das vorherige, zwangsweise materialisierte Verhalten.

Wird die alte, materialisierte Semantik für einen bestimmten Anwendungsfall weiterhin bewusst benötigt, etwa für eine rekursive CTE, eine CTE mit Seiteneffekten durch DATA-MODIFYING-Anweisungen, oder gezielt als Optimization Fence, lässt sich das explizit über das Schlüsselwort MATERIALIZED bei der CTE-Definition erzwingen. Umgekehrt erlaubt NOT MATERIALIZED, das Inlining explizit zu verlangen, auch wenn der Optimizer im Zweifel anders entscheiden würde.

-- PostgreSQL 12+: explizite Kontrolle über Materialisierung
WITH filtered_orders AS MATERIALIZED (
    SELECT customer_id, order_id, total_amount
    FROM orders
    WHERE status = 'completed'
),
recent_orders AS NOT MATERIALIZED (
    SELECT * FROM filtered_orders
    WHERE order_id > 1000000
)
SELECT customer_id, COUNT(*) FROM recent_orders GROUP BY customer_id;

5. Materialisierungsverhalten in anderen Datenbanksystemen

SQL Server behandelt CTEs grundsätzlich als reine Textersetzung, ähnlich einer Sicht, und materialisiert sie standardmäßig nicht als eigenständiges Zwischenergebnis, der Optimizer betrachtet die gesamte Abfrage einschließlich aller CTE-Definitionen als ein zusammenhängendes Ganzes. Das entspricht im Grundsatz dem neuen PostgreSQL-12-Verhalten, allerdings ohne die explizite Kontrollmöglichkeit über MATERIALIZED oder NOT MATERIALIZED, die PostgreSQL bietet.

MySQL folgt seit der Einführung von CTEs in Version 8.0 ebenfalls primär einem Inlining-Ansatz ähnlich SQL Server, mit einer wichtigen Ausnahme: Wird eine CTE mehrfach innerhalb derselben Abfrage referenziert, materialisiert MySQL sie in bestimmten Fällen dennoch automatisch, um eine mehrfache Neuberechnung zu vermeiden. Oracle wiederum entscheidet je nach Kostenschätzung des Optimizers fallweise zwischen Inlining und Materialisierung, ohne dass Entwickler diese Entscheidung wie in PostgreSQL explizit erzwingen könnten, was portable Performance-Vorhersagen zwischen den Systemen zusätzlich erschwert.

6. Das Mehrfachreferenzierungs-Problem in CTE-Ketten

Ein besonders relevanter Sonderfall entsteht, wenn eine einzelne CTE innerhalb der Kette mehrfach von nachfolgenden CTEs oder der Hauptabfrage referenziert wird. Auf Datenbanken mit striktem Inlining-Verhalten kann das dazu führen, dass die zugrunde liegende Logik der referenzierten CTE bei jeder Referenz erneut vollständig ausgewertet wird, statt einmal berechnet und mehrfach wiederverwendet zu werden, was bei rechenintensiven Zwischenschritten die Gesamtlaufzeit deutlich in die Höhe treiben kann.

In PostgreSQL 12 und neuer lässt sich dieses Problem gezielt durch explizites MATERIALIZED an genau dieser einen, mehrfach referenzierten CTE lösen, ohne die gesamte Kette zu materialisieren und damit andere, sinnvoll inlining-fähige Teile der Abfrage unnötig zu verlangsamen. Auf Datenbanken ohne diese explizite Kontrolle bleibt oft nur der Ausweg, den betreffenden Zwischenschritt bewusst in eine temporäre Tabelle statt eine reine CTE auszulagern, wenn Messungen tatsächlich eine mehrfache Neuberechnung als Ursache bestätigen.

7. Ab wann eine CTE-Kette zum echten Performance-Problem wird

Eine pauschale Zahl für die maximal sinnvolle Anzahl verketteter CTEs existiert nicht, in der Praxis zeigen sich jedoch wiederkehrende Warnsignale. Wenn eine Kette aus mehr als sechs bis acht Schritten entsteht, bei der jeder Schritt substanzielle Datenmengen verarbeitet und mehrfach referenziert wird, wird es zunehmend schwierig, den vom Optimizer gewählten Gesamtplan noch intuitiv nachzuvollziehen, selbst auf Datenbanken mit vollständigem Inlining. Ein einzelner, ungünstig gewählter Join-Typ tief in der Kette kann sich dann auf die gesamte nachfolgende Verarbeitung auswirken, ohne dass die Ursache aus dem SQL-Text allein ersichtlich wäre.

Ein zuverlässiges Warnsignal in der Praxis ist eine deutliche Diskrepanz zwischen der erwarteten und der tatsächlichen Laufzeit einer langen CTE-Kette, sichtbar in EXPLAIN ANALYZE anhand stark abweichender geschätzter und tatsächlicher Zeilenzahlen an einer bestimmten Stelle der Kette. In solchen Fällen lohnt sich häufig eine Aufteilung der Kette in mehrere unabhängige Abfragen mit Zwischenspeicherung in echten temporären Tabellen, kombiniert mit gezielten Indizes auf den Zwischenergebnissen, statt eine immer weiter wachsende einzelne WITH-Kette zu pflegen.

-- Bei sehr langen Ketten: expliziter Zwischenschritt als Temp-Tabelle
CREATE TEMP TABLE temp_customer_totals AS
SELECT customer_id, COUNT(*) AS order_count, SUM(total_amount) AS total_spent
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '365 days'
GROUP BY customer_id;

CREATE INDEX ON temp_customer_totals (total_spent);

-- Nachfolgende Schritte greifen auf die indizierte Temp-Tabelle zu
WITH ranked_customers AS (
    SELECT customer_id, order_count, total_spent,
           PERCENT_RANK() OVER (ORDER BY total_spent) AS spend_percentile
    FROM temp_customer_totals
)
SELECT * FROM ranked_customers WHERE spend_percentile >= 0.9;

8. Lesbarkeit ist nicht das alleinige Entscheidungskriterium

Auch wenn Lesbarkeit ein starkes Argument für CTE-Ketten ist, sollte sie nicht das einzige Kriterium bei der Entscheidung zwischen einer WITH-Kette, einer temporären Tabelle und einer materialisierten Sicht sein. Für wiederkehrende, rechenintensive Zwischenergebnisse, die von mehreren unabhängigen Abfragen im selben System genutzt werden, ist eine echte, persistente Zwischentabelle mit eigenem Refresh-Zyklus oft die bessere Wahl, selbst wenn dadurch etwas Lesbarkeit im Vergleich zu einer inline formulierten CTE-Kette verloren geht.

Umgekehrt gilt für einmalige, ad hoc formulierte Analyseabfragen, dass eine gut strukturierte CTE-Kette fast immer die richtige Wahl ist, weil hier die schnelle Verständlichkeit und die einfache Anpassbarkeit deutlich schwerer wiegen als eine im Millisekundenbereich messbare Performance-Differenz. Die Entscheidung sollte also stets im Kontext der konkreten Nutzung getroffen werden, nicht als pauschale Stilregel für alle Abfragen eines Projekts.

9. Best Practices für die Strukturierung langer CTE-Ketten

Bewährt hat sich, jede CTE auf genau eine klar abgrenzbare fachliche Aufgabe zu beschränken, etwa Filtern, Aggregieren oder Anreichern, statt mehrere Aufgaben in einer einzigen CTE zu bündeln. Diese Trennung erleichtert nicht nur das Verständnis, sondern auch das gezielte Debugging einzelner Schritte, da sich jede Zwischen-CTE isoliert per SELECT abfragen lässt, ohne die restliche Kette anpassen zu müssen.

Bei besonders langen Ketten empfiehlt sich zudem ein kurzer Kommentar oberhalb jeder CTE-Definition, der in einem Satz die fachliche Aufgabe des Schritts zusammenfasst, ähnlich einer Zwischenüberschrift in einem längeren Dokument. Kombiniert mit sprechenden CTE-Namen und einer bewussten Entscheidung über Materialisierung dort, wo die Datenbank diese Kontrolle bietet, bleibt eine CTE-Kette auch bei sechs oder mehr Schritten für neue Teammitglieder gut nachvollziehbar.

10. Zusammenfassung

11. FAQ: CTEs verketten: Das Wichtigste auf einen Blick