Entwickler müssen indizieren


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üs­sen, 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 Datenbankadmi­nistratoren (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.

Die passende Tasse zu dieser Website findest du in unserem Shop.
Sieht gut aus und unterstützt meine Arbeit hier.

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 Beispiel LIKE.

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 und group 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 und insert Skripte für die Tabellen im Buch.

Über den Autor

Photo of Markus Winand
Markus Winand stimmt Entwickler auf SQL-Performance ein. Er hat das Buch SQL Performance Explained veröffentlicht und bietet inhouse Schulungen sowie Tuning-Leistungen auf http://winand.at/ an.