Subqueries in WHERE

Drei Formen von Subqueries in WHERE

Alle drei sind nützlich — und in vielen Fällen austauschbar. Der Unterschied liegt oft in Lesbarkeit und Performance.

Skalar-Subqueries — ein einzelner Wert

Eine Subquery, die genau einen Wert liefert, kann wie ein Konstanten-Vergleich verwendet werden:

SELECT id, total
FROM orders
WHERE total > (SELECT avg(total) FROM orders)
ORDER BY total DESC;

Postgres berechnet avg(total) einmal (es ist konstant für die ganze Query) und vergleicht jede Zeile damit.

Wichtig: die Subquery muss garantiert genau einen Wert liefern. Wenn sie mehr Zeilen liefert, gibt's einen Laufzeit-Fehler:

myapp=> SELECT id FROM orders
        WHERE total > (SELECT total FROM orders LIMIT 10);
ERROR:  more than one row returned by a subquery used as an expression

Lösung: Aggregat (max(total), avg(total)) oder LIMIT 1 plus klares Sortier-Kriterium.

IN mit Subquery — Liste von Werten

Wenn man eine Liste von IDs/Werten dynamisch ermitteln will, ist IN mit Subquery der Klassiker:

SELECT id, name
FROM customers
WHERE id IN (SELECT customer_id FROM orders WHERE status = 'paid');

Liest sich wie der Code-Pseudocode: „nimm Kunden, deren id in der Liste der Customer-IDs aus paid-Orders steht".

NOT IN als Inverse:

-- Kunden ohne bezahlte Bestellung
SELECT id, name
FROM customers
WHERE id NOT IN (SELECT customer_id FROM orders WHERE status = 'paid');

Falle: wenn die Subquery NULL-Werte liefert (z. B. weil eine Bestellung customer_id = NULL hat), schlägt NOT IN für alle Zeilen fehl — ein klassischer SQL-Bug. Detail im Artikel EXISTS vs. IN vs. JOIN.

EXISTS — gibt's mindestens eine Zeile?

EXISTS (subquery) ist TRUE, sobald die Subquery mindestens eine Zeile liefert. Inhalt der Subquery ist dabei egal — Konvention ist SELECT 1 FROM …:

SELECT c.id, c.name
FROM customers c
WHERE EXISTS (
    SELECT 1 FROM orders o
    WHERE o.customer_id = c.id
      AND o.status = 'paid'
);

Diese Form ist korreliert — die innere Subquery referenziert c.id aus der äußeren Query. Das ist erlaubt und der häufige Use-Case.

Postgres optimiert EXISTS clever: sobald eine passende Zeile gefunden ist, hört die Subquery auf zu suchen. Bei großen Datenmengen oft schneller als IN-Subquery.

NOT EXISTS als Inverse — und im Gegensatz zu NOT IN NULL-sicher:

SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1 FROM orders o
    WHERE o.customer_id = c.id
);

Korreliert vs. unkorreliert

Eine Subquery ist korreliert, wenn sie auf Spalten der äußeren Query zugreift. Sonst unkorreliert.

SELECT * FROM products
WHERE price > (SELECT avg(price) FROM products);
--                                          ^
-- Subquery referenziert NICHT die äußere Tabelle.
-- Wird einmal berechnet, der Wert wird gegen jede Zeile getestet.

SELECT c.name,
       (SELECT count(*) FROM orders o WHERE o.customer_id = c.id) AS orders_count
--                                                       ^
-- Subquery referenziert c.id — wird pro Kunden-Zeile ausgewertet
FROM customers c;

Performance-Implikation: unkorrelierte Subqueries sind meist günstig (laufen einmal). Korrelierte können teuer sein — sie laufen einmal pro äußerer Zeile, wenn der Optimizer das nicht zu einem Hash-Join transformieren kann.

Bei EXISTS ist die Korrelation idiomatisch; Postgres optimiert das gut. Bei skalaren korrelierten Subqueries in SELECT (Beispiel oben) lieber prüfen, ob ein LEFT JOIN mit GROUP BY schneller wäre.

ANY und ALL

Zwei weniger bekannte Operatoren für Listen-Subqueries:

-- Bestellungen, die größer sind als alle bezahlten Bestellungen
SELECT id, total FROM orders
WHERE total > ALL (
    SELECT total FROM orders WHERE status = 'paid'
);

-- Bestellungen, die größer sind als mindestens eine paid-Bestellung
SELECT id, total FROM orders
WHERE total > ANY (
    SELECT total FROM orders WHERE status = 'paid'
);

In der Praxis selten — meist werden dieselben Selektionen mit MAX(...)/MIN(...)-Subqueries und einfachem Vergleich gemacht (lesbarer).

Subqueries vs. Joins — wann was?

Viele Subquery-Filter lassen sich auch als Joins formulieren:

SELECT id, name FROM customers
WHERE id IN (SELECT customer_id FROM orders WHERE status = 'paid');

SELECT DISTINCT c.id, c.name
FROM customers c
INNER JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'paid';

Beide Resultate identisch. Welche Variante besser ist, hängt vom Kontext ab:

• Subquery ist meist lesbarer für „Filter": die Absicht „nimm nur Kunden, die …" ist klar.
• Join ist nötig, sobald du Spalten aus der zweiten Tabelle anzeigen willst (mehr als nur als Filter).
• EXISTS ist NULL-sicher und oft am performantesten.
• DISTINCT im Join ist nötig, wenn ein Kunde mehrere passende Bestellungen hat — sonst Duplikate.

Eine ausführlichere Performance-Diskussion mit Benchmarks: EXISTS vs. IN vs. JOIN.

Weiterführende Ressourcen

Externe Quellen

• Subquery Expressions – PostgreSQL Documentation
• SELECT Statement – PostgreSQL Documentation
• Comparison Operators

Verwandte Artikel

• EXISTS vs. IN vs. JOIN
• INNER und OUTER Join
• SELECT und WHERE
• NULL und Three-Valued Logic