von Markus Winand.

Die Join-Operation


An SQL query walks into a bar and sees two tables.
He walks up to them and asks “Can I join you?”

— Quelle: Unbekannt

Eine Join-Operation transformiert Daten aus einem normalisierten Modell in eine denormalisierte Form, die für eine bestimmte Aufgabe benötigt wird. Da sie verstreute Daten-Fragmente zusammenführt, ist die Ge­schwin­dig­keit einer Join-Operation besonders empfindlich auf Fest­plat­ten-Latenzen. Auch hier ist eine sorgfältige Indizierung die beste Methode, die Antwortzeiten zu verbessern. Bei einem Join hängt die richtige Indizie­rung allerdings davon ab, welcher der drei gängigen Algorithmen zur Anwen­dung kommt.

Hinweis in eigener Sache

Ich lebe von SQL-Schulungen, SQL-Tuning und Beratung sowie dem Verkauf meines Buches „SQL Performance Explained“. Mehr auf winand.at.

Eines gilt aber für alle Join-Algorithmen gleichermaßen: Sie verarbeiten jeweils nur zwei Tabellen auf einmal. Ein SQL-Join mit mehreren Tabellen wird schrittweise ausgeführt: Zuerst werden zwei Tabellen zusammen­gefügt, dann das Zwischenergebnis mit der nächsten. Und so weiter.

Zwischenergebnisse „am Fließband“

Obwohl man sich den Algorithmus mit einem Zwischenergebnis sehr gut vorstellen kann, heißt das nicht, dass die Datenbank das Zwischenergebnis materialisieren muss. Das würde bedeuten, die erste Join-Operation vollständig auszuführen und das Zwischen­er­gebnis im Speicher abzulegen. Stattdessen wird eine Join-Operation möglichst „am Fließband“ ausgeführt (pipelined execution), um den Speicherbedarf zu reduzieren. Dabei wird jede Zeile des Zwi­schen­ergebnisses wie am Fließband direkt zur nächsten Operation weitergeleitet.

Obwohl die Reihenfolge der einzelnen Join-Operationen dabei keinen Einfluss auf das Endergebnis hat, wirkt sie sich dennoch auf die Per­for­mance aus. Der Optimizer bewertet daher alle Varianten mit einem Cost-Wert und wählt letztendlich die beste Reihenfolge aus. Das bedeutet aber, dass das Optimieren einer komplexen Abfrage selbst zum Performance-Problem werden kann. Je mehr Join-Operationen vorkommen, desto mehr Ausführungsplan-Varianten muss der Optimizer bewerten – mathematisch ausgedrückt: n! (Fakultät). Wenn man Bind-Parameter verwendet, ist das allerdings kein Problem.

Wichtig

Je komplexer eine SQL-Anweisung wird, desto wichtiger sind Bind-Parameter.

Keine Bind-Parameter zu verwenden, ist, als würde man ein Programm jedes Mal neu kompilieren.

Inhalt

  1. Nested Loops – verschachtelte Schleifen — Das ORM N+1 Problem

  2. Hash Join — Benötigt eine völlig andere Indizierung

  3. Sort-Merge Join ‌— Wie ein Zipverschluss auf sortierten Daten

Vorherige SeiteNächste Seite

Über den Autor

Foto von Markus Winand

Markus Winand ist der SQL Renaissance Botschafter auf der Mission, Entwickler auf die Evolution von SQL im 21. Jahrhundert aufmerksam zu machen. Markus kann als Trainer, Sprecher und Berater auf winand.at engagiert werden.

Sein Buch kaufen

Titelbild von „SQL Performance Explained“: Eichhörnchen läuft durchs Grass

Die Essenz: SQL-Tuning auf 200 Seiten

Jetzt Kaufen
(Taschenbuch und/oder PDF)

Sein Training

Markus verwandelt veraltetes SQL-92-Wissen in solides und zeitgemäßes SQL-Know-how

Erfahren Sie mehr»

Nicht mit OFFSET blättern

Mehr info

Besuche meine Schwester-Seite!Seit SQL-92 hat sich einiges getan!

Die Use The Index, Luke! Tasse

Aufkleber, Bierdeckel, Bücher und Kaffeetassen. Alles was man beim Lernen braucht!

Zum Shop

Mit Markus Winand verbinden

Markus Winand auf LinkedInMarkus Winand auf XINGMarkus Winand auf Twitter
„Use The Index, Luke!“ von Markus Winand ist unter einer Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License lizenziert.
Impressum | Kontakt | KEINE GEWÄHR | Handelsmarken | Datenschutz und DSGVO | CC-BY-NC-ND 3.0 Lizenz