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

Wenn Dir dieser Artikel gefällt, könnte mein Buch SQL Performance Explained oder mein Training auch etwas für Dich sein.

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 lehrt effizientes SQL – inhouse und online. Er minimiert die Entwicklungszeit durch modernes SQL und optimiert die Laufzeit durch schlaue Indizierung – dazu hat er auch das Buch SQL Performance Explained veröffentlicht.

Sein Buch bei Amazon kaufen

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

Die Essenz: SQL-Tuning auf 200 Seiten

Bei Amazon kaufen
(Taschenbuch)

Taschenbuch und PDF auch auf Markus' Webseite erhältlich.

Sein Training

Sein beliebtes Training stimmt Entwickler auf SQL Performance ein.

Erfahren Sie mehr»

„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 | CC-BY-NC-ND 3.0 Lizenz