Implizite Joins vs. explizite JOIN-Syntax: warum die Komma-Schreibweise riskant bleibt

1. Was die implizite Komma-Syntax technisch bedeutet

Bei der impliziten Join-Syntax werden mehrere Tabellen einfach durch Kommas getrennt in der FROM-Klausel aufgeführt, und die eigentliche Join-Bedingung wandert vollständig in die WHERE-Klausel. Aus Sicht des SQL-Standards ist das kein separates Sprachkonstrukt, sondern schlicht ein CROSS JOIN, also die Bildung aller möglichen Kombinationen von Zeilen aus beiden Tabellen, gefolgt von einer Filterung über WHERE, die diese Kombinationen auf die tatsächlich zusammengehörigen Zeilenpaare reduziert.

Syntaktisch entspricht FROM a, b WHERE a.id = b.a_id also exakt FROM a CROSS JOIN b WHERE a.id = b.a_id. Der Optimierer der meisten modernen Datenbanksysteme erkennt dieses Muster und wandelt es intern in einen regulären INNER JOIN um, sodass sich die beiden Schreibweisen bei korrekt formulierter WHERE-Bedingung in der Praxis nicht in der Ausführungsgeschwindigkeit unterscheiden.

Der fundamentale Unterschied liegt nicht in der Performance einer korrekten Abfrage, sondern in der Fehlerklasse, die jede Schreibweise zulässt. Die Komma-Syntax koppelt die Join-Bedingung syntaktisch nicht an die beteiligten Tabellen, sie ist nur eine von potenziell vielen WHERE-Bedingungen und dadurch leicht zu übersehen oder versehentlich wegzulassen.

-- Implizite Syntax: Join-Bedingung steckt in der WHERE-Klausel
SELECT o.id, c.name
FROM orders o, customers c
WHERE o.customer_id = c.id
  AND o.status = 'shipped';

-- Explizite Syntax: Join-Bedingung ist syntaktisch an den JOIN gebunden
SELECT o.id, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'shipped';

2. Wie eine vergessene WHERE-Bedingung zum kartesischen Produkt wird

Der praktisch gefährlichste Fall zeigt sich, wenn bei der Komma-Syntax die Join-Bedingung schlicht fehlt, sei es durch einen Tippfehler, ein versehentlich gelöschtes AND, oder weil beim nachträglichen Hinzufügen einer dritten Tabelle eine der notwendigen Bedingungen vergessen wird. Das Ergebnis ist kein Syntaxfehler, sondern ein kartesisches Produkt: jede Zeile der ersten Tabelle wird mit jeder Zeile der zweiten Tabelle kombiniert.

Bei zwei Tabellen mit jeweils tausend Zeilen entstehen daraus eine Million Ergebniszeilen, die Abfrage läuft weiter, liefert scheinbar plausible Daten und erzeugt in vielen Fällen keinen offensichtlichen Fehler, insbesondere wenn die Anwendung nur die ersten paar Zeilen des Ergebnisses anzeigt oder verarbeitet. Genau diese Unauffälligkeit macht den Fehler so gefährlich: Er fällt oft nicht bei der Entwicklung mit kleinen Testdatenmengen auf, sondern erst in der Produktion mit echten Datenmengen, wo er zu drastisch erhöhter Last, zeitweisen Timeouts oder offensichtlich falschen Report-Zahlen führt.

Bei expliziter JOIN-Syntax ist dieses Fehlerbild strukturell erschwert. Ein JOIN ohne ON-Klausel ist entweder ein Syntaxfehler, der die Abfrage sofort ablehnt, oder erfordert die explizite und damit bewusste Verwendung von CROSS JOIN, die kaum versehentlich passiert, weil sie ein anderes Schlüsselwort ist als das gewohnte JOIN und daher optisch auffällt.

-- Gefährlich: fehlt die zweite Zeile, entsteht ein kartesisches Produkt
SELECT o.id, c.name, i.product_name
FROM orders o, customers c, order_items i
WHERE o.customer_id = c.id;
-- Fehlende Bedingung: AND i.order_id = o.id
-- Ergebnis: jede Bestellung mit jeder Position aller anderen Bestellungen

-- Explizites JOIN erzwingt eine ON-Klausel pro Tabelle,
-- ein Syntaxfehler zeigt das Problem sofort beim Schreiben an
SELECT o.id, c.name, i.product_name
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items i ON i.order_id = o.id;

3. Lesbarkeitsvorteil expliziter JOIN-Syntax bei vielen Tabellen

Bei einer Abfrage über zwei Tabellen ist der Lesbarkeitsunterschied zwischen beiden Schreibweisen gering. Sobald jedoch fünf, sechs oder mehr Tabellen beteiligt sind, wie es bei komplexen Reporting-Queries üblich ist, zeigt sich ein deutlicher Unterschied: Bei der Komma-Syntax stehen alle Join-Bedingungen ununterscheidbar zwischen den fachlichen Filterbedingungen in einer einzigen, oft langen WHERE-Klausel. Ein Leser muss jede einzelne Bedingung analysieren, um zu erkennen, ob sie eine Join-Beziehung oder eine reine Datenfilterung ausdrückt.

Bei expliziter JOIN-Syntax steht jede Join-Bedingung direkt neben der Tabelle, zu der sie gehört, in der Reihenfolge, in der die Tabellen tatsächlich verknüpft werden. Diese räumliche Nähe zwischen JOIN-Schlüsselwort, Tabellenname und ON-Bedingung macht die Struktur der Abfrage auf einen Blick erkennbar, ohne die gesamte WHERE-Klausel gedanklich in Join- und Filterbedingungen aufteilen zu müssen.

Ein weiterer Lesbarkeitsvorteil zeigt sich bei OUTER JOINs. LEFT JOIN, RIGHT JOIN und FULL OUTER JOIN lassen sich mit reiner Komma-Syntax gar nicht oder nur über datenbankspezifische, nicht standardisierte Erweiterungen ausdrücken, was Portabilität und Lesbarkeit zusätzlich beeinträchtigt. Explizite JOIN-Syntax deckt dagegen alle Join-Typen einheitlich und standardkonform ab.

4. Historischer Kontext: warum die Komma-Syntax überhaupt noch vorkommt

Die explizite JOIN-Syntax mit dem Schlüsselwort JOIN und der ON-Klausel wurde erst mit dem SQL-92-Standard eingeführt. Vor diesem Standard war die Komma-Syntax die einzige Möglichkeit, mehrere Tabellen in einer Abfrage zu kombinieren, und viele Datenbanksysteme sowie Lehrbücher aus dieser Zeit haben sie entsprechend als Standardmuster etabliert. Wer SQL in den neunziger Jahren oder früher gelernt hat, hat diese Schreibweise oft als erste und einzige Join-Form kennengelernt.

Diese historische Prägung wirkt bis heute nach, sowohl in der Ausbildung als auch in bestehendem Code. Viele Legacy-Codebasen, die über Jahrzehnte gewachsen sind, enthalten noch Komma-Joins aus einer Zeit, in der sie schlicht die einzige verfügbare Syntax waren, und diese Abfragen laufen weiterhin unverändert, weil sie funktionieren und ein Refactoring ohne konkreten Anlass selten priorisiert wird.

Ein weiterer Grund für das Fortbestehen ist, dass die Komma-Syntax bei einfachen Zwei-Tabellen-Abfragen tatsächlich funktioniert und auf den ersten Blick kürzer wirkt, sodass sie in Tutorials, Stack-Overflow-Antworten und schnell zusammengeklickten Abfragen weiterhin auftaucht, obwohl der SQL-92-Standard mittlerweile über drei Jahrzehnte alt ist und explizites JOIN in praktisch jedem modernen Datenbanksystem vollständig unterstützt wird.

5. Gibt es tatsächliche Performance-Unterschiede zwischen beiden Schreibweisen?

Bei korrekt formulierter WHERE-Bedingung erzeugen die meisten modernen Datenbanksysteme für beide Schreibweisen denselben oder einen sehr ähnlichen Ausführungsplan, weil der Optimierer die Join-Bedingung unabhängig davon erkennt, ob sie syntaktisch in einer ON-Klausel oder einer WHERE-Klausel steht. Ein EXPLAIN-Vergleich zwischen einer sauber geschriebenen Komma-Abfrage und der äquivalenten expliziten JOIN-Abfrage zeigt in der Regel identische Pläne.

Ein relevanter Unterschied entsteht aber bei der Reihenfolge, in der ein Optimierer mehrere Join-Bedingungen zuordnet, insbesondere bei sehr komplexen Abfragen mit vielen Tabellen und gemischten INNER- und OUTER-Join-Anforderungen. Explizite JOIN-Syntax erlaubt es, die Join-Reihenfolge und den Join-Typ pro Tabellenpaar präzise zu kontrollieren, was bei der Komma-Syntax für OUTER JOINs praktisch nicht sauber möglich ist und daher indirekt auch zu suboptimalen Plänen führen kann, wenn Entwickler auf datenbankspezifische Ersatzkonstruktionen ausweichen.

Der eigentliche Performance-Unterschied zwischen beiden Schreibweisen zeigt sich also fast nie bei korrektem Code, sondern indirekt über die höhere Fehlerwahrscheinlichkeit der Komma-Syntax: Ein versehentliches kartesisches Produkt ist immer erheblich langsamer als jeder korrekt geplante Join, unabhängig von der gewählten Syntax.

6. Warum gemischte Schreibweisen in einer Abfrage vermieden werden sollten

Manche Abfragen kombinieren explizites JOIN für einen Teil der Tabellen mit Komma-Syntax für weitere Tabellen. Das ist syntaktisch gültig, erhöht aber die kognitive Last beim Lesen erheblich, weil ein Leser zwei unterschiedliche mentale Modelle gleichzeitig anwenden muss, um die vollständige Join-Struktur zu rekonstruieren. Besonders in Kombination mit OUTER JOINs kann diese Mischung zu unerwarteten Ergebnissen führen, weil die Rangfolge, in der Bedingungen ausgewertet werden, von der jeweiligen Syntax abhängt.

Ein Team-Styleguide sollte deshalb nicht nur explizite JOIN-Syntax vorschreiben, sondern explizit auch gemischte Schreibweisen innerhalb derselben Abfrage untersagen. Diese Regel ist einfacher durchzusetzen als es zunächst scheint, weil moderne SQL-Formatter und Linter beide Muster zuverlässig erkennen und automatisiert markieren können.

Bei der Migration einer bestehenden Komma-Abfrage auf explizites JOIN empfiehlt sich außerdem, die Umstellung vollständig in einem Schritt durchzuführen, statt Tabelle für Tabelle schrittweise umzustellen. Eine halb migrierte Abfrage mit gemischter Syntax ist während der Übergangszeit schwerer zu überprüfen als sowohl die ursprüngliche als auch die vollständig migrierte Version.

7. Automatisierte Erkennung von Komma-Joins im Code Review

Die meisten SQL-Linter erkennen die Komma-Syntax als eigenständiges, prüfbares Muster: mehrere Tabellenverweise in der FROM-Klausel ohne JOIN-Schlüsselwort. Diese Prüfung lässt sich, ähnlich wie bei anderen SQL-Antipatterns, als verpflichtender Schritt in die CI-Pipeline integrieren, sodass ein Merge-Request mit neuer Komma-Syntax automatisch abgelehnt wird, bevor ein Mensch die Abfrage überhaupt manuell prüfen muss.

Für bestehenden Code, der noch flächendeckend Komma-Joins enthält, ist eine vollständige Migration in einem Schritt selten realistisch. Sinnvoller ist, den Linter zunächst nur für neuen und geänderten Code zu aktivieren, sodass keine rückwirkende Prüfung des gesamten Codebestands erzwungen wird, während jede neue Abfrage automatisch der strengeren Regel unterliegt.

Zusätzlich zur automatisierten Prüfung lohnt sich ein gezielter, manueller Audit der bestehenden Codebasis nach Abfragen, die mehr als zwei Tabellen über Komma-Syntax kombinieren, weil hier das Risiko einer fehlenden Bedingung am größten ist. Diese Abfragen sollten priorisiert migriert werden, unabhängig davon, wie lange die vollständige Umstellung des restlichen Bestands dauert.

-- Linter-Muster: mehrere FROM-Referenzen ohne JOIN-Keyword
-- werden als implizite Join-Syntax markiert
SELECT * FROM a, b, c WHERE a.id = b.a_id AND b.id = c.b_id;

8. Wenn ein kartesisches Produkt tatsächlich gewollt ist

Es gibt legitime Anwendungsfälle, in denen ein kartesisches Produkt tatsächlich das gewünschte Ergebnis ist, etwa beim Erzeugen aller Kombinationen aus einer Liste von Größen und einer Liste von Farben für eine Produktvariantenmatrix, oder beim Erzeugen einer Kalenderreihe durch Kreuzung einer Zahlenreihe mit einem Startdatum. In diesen Fällen sollte das explizite CROSS-JOIN-Schlüsselwort verwendet werden, niemals die Komma-Syntax ohne WHERE-Bedingung.

Der Unterschied ist rein kommunikativ, aber entscheidend für die Wartbarkeit: CROSS JOIN macht die Absicht des Entwicklers unmissverständlich explizit, während eine Komma-Syntax ohne erkennbare WHERE-Bedingung für den nächsten Leser nicht zu unterscheiden ist von einem vergessenen Join-Filter. Ein Code-Reviewer, der auf CROSS JOIN stößt, weiß sofort, dass das kartesische Produkt beabsichtigt ist, und muss nicht erst im Anwendungscode nachvollziehen, ob eine Bedingung fehlt.

Diese explizite Kennzeichnung zahlt sich besonders bei automatisierten Linting-Regeln aus: Eine Regel, die jede Komma-Syntax in der FROM-Klausel als Fehler markiert, erzeugt keine falschen Alarme für tatsächlich gewollte kartesische Produkte, weil diese über CROSS JOIN einen syntaktisch klar unterscheidbaren Weg nehmen.

-- Bewusst gewolltes kartesisches Produkt: Variantenmatrix erzeugen
SELECT s.size_label, col.color_name
FROM sizes s
CROSS JOIN colors col;

9. Praktische Migrationsstrategie für bestehende Komma-Joins

Der erste Schritt einer Migration ist eine automatisierte Bestandsaufnahme: ein Skript, das den gesamten SQL-Bestand nach dem Muster mehrerer kommagetrennter Tabellenverweise in der FROM-Klausel durchsucht und die Ergebnisse nach Anzahl der beteiligten Tabellen sortiert. Abfragen mit drei oder mehr Tabellen verdienen höchste Priorität, weil hier die Wahrscheinlichkeit einer fehlenden oder fehlerhaften Bedingung am größten ist.

Für jede migrierte Abfrage sollte vor und nach der Umstellung ein Vergleich der zurückgegebenen Zeilenanzahl und, wo möglich, ein Diff der tatsächlichen Ergebnisdaten erfolgen. Weichen die Ergebnisse voneinander ab, deutet das fast immer darauf hin, dass die ursprüngliche Komma-Abfrage bereits ein latentes, bisher unentdecktes Fehlverhalten enthielt, etwa eine unvollständige Bedingung, die die Migration jetzt aufdeckt.

Nach Abschluss der Migration lohnt sich eine dauerhafte Regel im Styleguide und eine entsprechende Linter-Konfiguration, die neue Komma-Joins vollständig unterbindet. Damit wird verhindert, dass der mühsam bereinigte Codebestand durch neue Beiträge schleichend wieder mit demselben Risiko belastet wird.

10. Zusammenfassung

11. FAQ: Implizite vs. explizite Joins: Das Wichtigste auf einen Blick