Probleme mit der Performance von SQL-Abfragen sind so alt wie SQL selbst. Manche sagen sogar, dass diese Sprache von Natur aus langsam sei. Das mag zwar gestimmt haben, als SQL noch jung war, heute ist es aber nicht mehr so. Dennoch sind SQL-Performance-Probleme alltäglich – wie kommt das?
SQL ist die vielleicht erfolgreichste Programmiersprache der vierten Generation (4GL). Dabei ist es das Ziel, das „Was“ vom „Wie“ zu trennen: Eine SQL-Anweisung beschreibt, was benötigt wird, ohne Anweisungen zu geben, wie das Ergebnis erreicht wird. Das folgende Beispiel verdeutlicht das:
SELECT date_of_birth
FROM employees
WHERE last_name = 'WINAND'
Diese SQL-Abfrage kann fast als englischer Satz gelesen werden. Er beschreibt, welche Daten benötigt werden. SQL-Anweisungen kann man generell ohne jegliches Wissen über das Storage-System (Festplatten, Dateien, Blöcke) und die Interna der Datenbank verfassen. Eine SQL-Anweisung beinhaltet keine Instruktionen, welche Schritte auszuführen sind, welche Dateien geöffnet werden müssen, oder wie man den gesuchten Tabelleneintrag findet. Man kann viele Jahre mit SQL arbeiten, ohne zu wissen, wie die Datenbank zu den Ergebnissen kommt.
Obwohl die Trennung der Zuständigkeiten bei SQL ungewöhnlich gut funktioniert, ist die Abstraktion nicht perfekt. Das Problem zeigt sich bei der Performance: Der Autor einer SQL-Anweisung muss per Definition nicht wissen, wie die Anweisung ausgeführt wird. Folgerichtig kann er auch nicht für die Ausführungsgeschwindigkeit verantwortlich sein. Die Erfahrung lehrt uns jedoch das Gegenteil: Der Autor muss ein wenig über die Datenbank wissen, um effiziente SQL-Anweisungen zu schreiben.
Bei näherer Betrachtung stellt sich heraus, dass Entwickler nur lernen müssen, wie man einen Index richtig einsetzt. Denn zur richtigen Indizierung ist die Kenntnis darüber, wie das Storage-System konfiguriert ist oder welche Hardware für die Datenbank benutzt wird, nicht wichtig. Zur erfolgreichen Indizierung muss man wissen, wie auf die Daten zugegriffen wird. Dieses Wissen über die Zugriffswege können sich Datenbankadministratoren (DBAs) oder externe Berater nur durch zeitaufwendiges Reverse-Engineering erarbeiten. In der Entwicklung ist es aber vorhanden.
Dieses Buch erklärt Entwicklern den Umgang mit Indizes – und nur das. Genau gesagt deckt das Buch nur den wichtigsten Index-Typ ab: den B-Tree-Index.
Der B-Tree-Index funktioniert in allen Datenbanken gleich. Das Buch verwendet in erster Linie die Begriffe der Oracle® Datenbank, verweist aber auf die entsprechenden Ausdrücke der anderen Datenbanken falls sie abweichen. Randnotizen geben weitere Informationen zu SQL Server®, MySQL und PostgreSQL.
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.
Die Struktur des Buches entspricht den Bedürfnissen von Entwicklern: Die meisten Kapitel entsprechen einem bestimmten Teil einer SQL-Anweisung.
- KAPITEL 1 — Anatomie eines Indexes
Das erste Kapitel ist das einzige, in dem keine SQL-Anweisungen vorkommen. Es beschreibt die Index-Struktur. Dieses Kapitel ist die Grundlage für alle folgenden und sollte keinesfalls übersprungen werden.
Obwohl das Kapitel nur acht Seiten hat, versteht man danach bereits, warum ein Index langsam sein kann.
- KAPITEL 2 — Die Where-Klausel
Das Kapitel erklärt alles rund um die
where
-Klausel; es beginnt mit einfachen Abfragen auf einzelnen Spalten und endet bei komplexen Bereichsabfragen und Spezialfällen wie zum BeispielLIKE
.Das Kapitel bildet den Hauptteil des Buches. Wer die hier beschriebenen Techniken beherrscht, wird bereits besseres SQL schreiben.
- KAPITEL 3 — Performance und Skalierbarkeit
Performance ist von vielen Faktoren abhängig. Hier werden einige davon gezeigt und erklärt, warum horizontale Skalierung (mehr Hardware) nicht die beste Antwort auf langsame Abfragen ist.
- KAPITEL 4 — Die Join-Operation
Zurück zu SQL: Wie benutzt man einen Index, um Joins zu optimieren?
- KAPITEL 5 — Daten-Cluster
Macht es einen Performanceunterschied, ob man nur eine Spalte oder alle Spalten selektiert? Die Antwort findet sich in diesem Kapitel – zusammen mit einem Trick für noch bessere Performance.
- KAPITEL 6 — Sortieren und Gruppieren
Wie
order by
undgroup by
von einem Index profitieren können.- KAPITEL 7 — Teilergebnisse
Dieses Kapitel zeigt, wie man von einer Ausführung „am Fließband“ profitieren kann, wenn man nur die ersten Zeilen benötigt.
- KAPITEL 8 — Insert, Delete und Update
Wie beeinflussen Indizes Schreibzugriffe? Indizes sind nicht kostenlos – verwende sie gezielt und sparsam!
- ANHANG A — Ausführungspläne
Der Datenbank das „Wie“ entlocken: Wie wird die Anweisung ausgeführt?
- ANHANG B — Mythen Verzeichnis
Die gängigsten Datenbank-Performance Mythen und der wahre Kern dahinter.
- ANHANG C — Beispiel Schema
Alle
create
undinsert
Skripte für die Tabellen im Buch.