INNER JOIN und LEFT JOIN

In einer relationalen Datenbank sind die Daten auf mehrere Tabellen verteilt – das ist der ganze Sinn der Normalisierung. Aber bei Auswertungen will man die Informationen wieder zusammenführen: „Welcher Kunde hat welche Bestellung getätigt?" – Kunden stehen in einer Tabelle, Bestellungen in einer anderen. Das Werkzeug, um sie zu verbinden, heißt JOIN.

JOINs sind das mächtigste Werkzeug von SQL und für viele auch das schwierigste Konzept zu Beginn. Diese Lektion zeigt dir die zwei wichtigsten Varianten: INNER JOIN (zeigt nur Übereinstimmungen) und LEFT JOIN (zeigt zusätzlich „verwaiste" Zeilen der linken Tabelle). Wer diese zwei beherrscht, deckt 90 % aller Praxisfälle ab. Die restlichen JOIN-Typen findest du in SQL Fortgeschritten.

1) Die Schlüsselbund-Analogie

Stell dir zwei Tabellen wie zwei Schlüsselbunde vor. Der eine (Kunde) hat Schlüssel kunden_id 1, 2, 3, 4. Der andere (Bestellung) hat Marken k_id 1, 1, 2, 5 – jede Bestellung weiß, zu welchem Kunden sie gehört. Ein JOIN ist die Frage: Welche Schlüssel passen zu welchen Marken?

• INNER JOIN: Nur Paare, bei denen beide Seiten zusammenpassen. Kunde 4 ohne Bestellungen wird ignoriert, Bestellung mit k_id=5 ohne passenden Kunden auch.
• LEFT JOIN: Alle Schlüssel des linken Bundes (Kunde 1, 2, 3, 4). Wenn keine passende Marke da ist, bleibt die Bestellungs-Seite leer (NULL).

Wichtig zu wissen: Die Verknüpfung erfolgt über einen Fremdschlüssel – siehe Primary & Foreign Key. In unserem Beispiel ist bestellung.k_id der FK auf kunde.kunden_id. Diese Verknüpfung wurde beim Schema-Entwurf festgelegt.

2) Venn-Diagramm-Visualisierung

Die klassische Darstellung von JOINs sind Venn-Diagramme: zwei Kreise, die sich überlappen. Der INNER JOIN ist der Schnittbereich, der LEFT JOIN ist der linke Kreis komplett. Klick durch die Varianten:

3) Die Grundform eines JOINs

So sieht ein typischer JOIN aus. Drei Komponenten musst du erkennen: die linke Tabelle (nach FROM), die rechte Tabelle (nach JOIN), und die Bedingung (nach ON):

SELECT k.name, b.bestell_nr, b.betrag
FROM kunde AS k
INNER JOIN bestellung AS b
  ON k.kunden_id = b.k_id;

Lies das wie folgt: „Verbinde die Kundentabelle mit der Bestelltabelle dort, wo die kunden_id mit der k_id der Bestellung übereinstimmt". Die ON-Klausel ist das Herz des JOINs – sie sagt, welche Spalten verglichen werden. Praktisch immer ist das ein Foreign Key mit dem zugehörigen Primary Key.

Die Tabellen-Aliase (k und b) sind technisch optional, aber praktisch unverzichtbar. Sie verhindern Tipparbeit (k.name statt kunde.name) und lösen Mehrdeutigkeit auf: wenn beide Tabellen eine Spalte name haben, muss man eindeutig sagen, welche gemeint ist.

4) JOIN-Builder zum Spielen

Hier sind zwei kleine Tabellen, die du auf verschiedene Weisen joinen kannst. Beobachte besonders, wie NULL-Werte erscheinen, wenn ein Kunde keine Bestellung hat oder eine Bestellung keinen Kunden:

5) INNER JOIN – wann passt der?

Der INNER JOIN ist der Default und der häufigste Anwendungsfall: „zeige mir Daten aus beiden Tabellen, wenn es einen Match gibt". Typische Beispiele:

• Bestellungen mit Kundennamen anreichern: „Zeige jede Bestellung mit Namen und Stadt des Kunden". Bestellungen ohne validen Kunden interessieren uns nicht – sind sowieso Datenfehler.
• Produkte mit Kategorie verknüpfen: Jedes Produkt hat eine Kategorie-ID, wir wollen den Kategorie-Namen mit ausgeben.
• Mehrere Tabellen kombinieren: Bestellposition → Bestellung → Kunde, alles mit INNER JOIN. Zeigt nur „komplette" Datenpfade.

Schreibweise-Tipp: Statt INNER JOIN reicht auch nur JOIN – INNER ist Default. Beide Versionen funktionieren überall. Manche Stilrichtlinien bevorzugen explizit INNER JOIN für bessere Lesbarkeit.

6) LEFT JOIN – wann ist der nötig?

LEFT JOIN ist immer dann richtig, wenn dich die linke Seite vollständig interessiert – auch ohne Match auf der rechten:

• Alle Kunden mit ihren Bestellungen anzeigen – auch frisch registrierte ohne Bestellung sollen erscheinen.
• Vollständige Produktliste, daneben aktuelle Lagerbestände – auch Produkte, deren Lagerbestands-Zeile noch nicht angelegt wurde.
• Mitarbeiter und ihre Projekte – auch Mitarbeiter ohne aktuelles Projekt.

Der charakteristische Trick: LEFT JOIN ... WHERE rechte_tabelle.spalte IS NULL findet genau die linken Zeilen ohne Match. „Kunden ohne Bestellung" – eine perfekte Marketing-Zielgruppe für Reaktivierungs-Kampagnen:

SELECT k.name, k.email
FROM kunde k
LEFT JOIN bestellung b ON k.id = b.k_id
WHERE b.nr IS NULL;
-- → alle Kunden, die nie bestellt haben

7) Alle JOIN-Typen im Überblick

Für die IHK-Grundlagen reichen INNER und LEFT. Aber gut zu wissen, was noch existiert:

SELECT ... FROM a
JOIN b ON a.id = b.aid;

SELECT ... FROM a
LEFT JOIN b ON ...;

SELECT ... FROM a
RIGHT JOIN b ON ...;

SELECT ... FROM a
FULL OUTER JOIN b ON ...;

SELECT ... FROM a
CROSS JOIN b;

SELECT m.name, c.name
FROM mitarb m
JOIN mitarb c ON m.chef_id = c.id;

8) JOINs über mehr als zwei Tabellen

In der Realität reicht oft eine Tabelle nicht. Eine Bestellung → Kunde → Stadt → Land braucht drei JOINs. Das geht ganz natürlich, indem man JOIN-Klauseln aneinanderkettet:

SELECT
  k.name,
  s.stadt_name,
  l.land_name,
  b.betrag
FROM bestellung b
INNER JOIN kunde k ON b.k_id = k.id
INNER JOIN stadt s ON k.stadt_id = s.id
INNER JOIN land l ON s.land_id = l.id;

Jeder JOIN braucht seine eigene ON-Bedingung. Die Reihenfolge der JOINs ist bei INNER JOINs egal, das DBMS optimiert intern. Bei gemischten LEFT/INNER JOINs ist die Reihenfolge wichtig – Faustregel: LEFT JOINs zuletzt, damit sie nicht versehentlich zu INNER JOINs werden.

9) JOINs und Performance

JOINs sind nicht „teuer", wenn sie auf Indizes treffen. Aber sie können dramatisch langsam werden, wenn man unbedacht große Tabellen verknüpft. Drei Faustregeln:

• JOIN-Spalten sollten indiziert sein. Foreign Keys sind in vielen DBMS nicht automatisch indiziert – manuell anlegen lohnt sich.
• Reduziere früh. Eine WHERE-Klausel, die 90 % der Zeilen filtert, ist besser vor dem JOIN gewirkt als danach. Das DBMS optimiert das oft selbst, aber nicht immer.
• Vermeide CROSS JOIN aus Versehen. Wenn du das ON vergisst (oder es überall TRUE wird), kombiniert das DBMS jede Zeile mit jeder. Bei zwei Tabellen mit je 100.000 Zeilen sind das 10 Milliarden Zeilen – die Anwendung steht.

Zusammenfassung

JOINs verbinden Daten aus mehreren Tabellen anhand einer gemeinsamen Spalte (typisch: Foreign Key → Primary Key). Die zwei wichtigsten Varianten: INNER JOIN liefert nur Zeilen, bei denen beide Tabellen einen Match haben (Standardfall, Default). LEFT JOIN liefert alle Zeilen der linken Tabelle, plus passende aus der rechten – fehlende rechte Werte werden NULL. RIGHT JOIN ist das Spiegelbild (selten genutzt, lieber Tabellen tauschen + LEFT). FULL OUTER JOIN liefert beide Seiten komplett (nicht in MySQL). CROSS JOIN ist das kartesische Produkt (M×N Zeilen, fast immer ein Bug). SELF JOIN verknüpft eine Tabelle mit sich selbst (z. B. für Vorgesetzten-Beziehungen). Standardform: FROM a JOIN b ON a.id = b.aid mit Tabellen-Aliasen für Lesbarkeit. LEFT JOIN + WHERE B.x IS NULL findet Zeilen ohne Match (z. B. „Kunden ohne Bestellung"). Mehrere JOINs werden aneinandergekettet, jeder mit eigener ON-Bedingung. Performance hängt von Indizes auf JOIN-Spalten ab.

Verwandte Lektionen: JOINs vertieft · Primary & Foreign Key · SELECT Grundabfragen · und mehrWeitere relevante LektionenER-Modell zu SchemaKardinalitätenAggregatfunktionenGROUP BY und HAVINGSubqueriesDatenbankindizesReferenzielle Integrität