SQL: Unterabfrage (Subquery) vs. JOIN – wann brauche ich welche?

Gute Frage, das ist genau der Punkt, an dem SQL „klick“ macht 🙂 Faustregel:

• JOIN, wenn du Spalten aus mehreren Tabellen im Ergebnis zusammenführen willst (Kundenname und die zugehörigen Bestellungen nebeneinander).
• Unterabfrage, wenn du nur filtern willst und die zweite Tabelle gar nicht anzeigen musst – z. B. „alle Kunden, die schon mal bestellt haben“.

Beispiel für den Filterfall:

• Mit Subquery: SELECT name FROM kunde WHERE kundeNr IN (SELECT kundeNr FROM bestellung)
• Mit JOIN: SELECT DISTINCT k.name FROM kunde k JOIN bestellung b ON k.kundeNr = b.kundeNr

Beim JOIN brauchst du hier das DISTINCT, weil ein Kunde mit fünf Bestellungen sonst fünfmal auftaucht. Die Subquery mit IN hat das Problem nicht – ein netter Grund, für reine Existenz-Filter die Unterabfrage zu nehmen.

Zum „JOINs sind immer schneller“: Das ist tatsächlich ein Mythos. Bei modernen Datenbanken formt der Query-Optimizer viele Unterabfragen intern ohnehin in JOINs um – die Laufzeit ist dann gleich. Wichtiger als JOIN-vs-Subquery sind meist die Indizes auf den Verknüpfungsspalten.

Einen Fall solltest du aber kennen: die korrelierte Unterabfrage, die sich für jede Zeile der äußeren Abfrage neu ausführt – die kann bei großen Tabellen wirklich bremsen. Für „gibt es mindestens einen Treffer?“ ist EXISTS oft die sauberste und schnellste Variante, weil die Datenbank beim ersten Treffer abbricht. Und Vorsicht bei NOT IN in Kombination mit NULL-Werten – das liefert gern mal gar keine Zeilen; da ist NOT EXISTS die robustere Wahl.