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 biete SQL Schulungen, Optimierung und Beratung an. Auch der Kauf meines Buches „SQL Performance Explained“ (ab €9,95) unterstützt meine Arbeit an dieser Webseite.

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

Du kannst nicht alles an einem Tag lernen. Abonniere den Newsletter via E-Mail, Twitter oder RSS um sukzessive aufzuholen. Und sieh dir auch modern-sql.com an.

Über den Autor

Foto von Markus Winand

Markus Winand gibt auf modern-sql.com Einblick in SQL und zeigt, wie es von verschiedenen Systemen unterstützt wird. Zuvor machte er use-the-index-luke.com, was er noch immer wartet. 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»

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