ADMIN Magazin Gestapelt - Schneller und sicherer mit RAID (Vorschau)

Ausführungspläne
Basics
Weniger bekannt, aber nicht weniger
nützlich ist, dass man aus Ausführungsplänen
auch etwas über den Speicherbedarf
einer SQL-Abfrage erfahren kann
– also darüber, wie viel Hauptspeicher
während der Ausführung benötigt wird.
Speicherbedarf
Dafür kann man die Operationen, die im
Ausführungsplan angezeigt werden, in
zwei Kategorien unterteilen:
n jene, die generell nur einen geringen
Speicherbedarf haben und
n jene, die ein Zwischenergebnis im Arbeitsspeicher
ablegen müssen und damit
einen potenziell großen Speicherbedarf
haben.
Bei der Ressourcenplanung braucht man
sich freilich nur um die zweite Kategorie
kümmern. Das sind vor allem Sortier- und
Gruppieroperationen aber auch sämtliche
Operationen, die einen Hash-Algorithmus
verwenden – etwa der Hash-Join. Obwohl
die Namen dieser Operationen in
den verschiedenen Datenbank-Produkten
abweichen, verraten sich die Speicherintensiven
meist durch „Sort“, „Group“
oder „Hash“ im Namen. Dennoch gibt
es auch Spezialfälle wie die Operation
»SORT GROUP BY NOSORT« der Oracle
Beispiel 4: MySQL-Ausführungsplan erklärt
01 sqyl> EXPLAIN 1
02 ‐> SELECT *
03 ‐>
04 FROM sales s
05 ‐>
06 JOIN employees e ON (s.employee_id = e.employee_id)
07 ‐>
08 WHERE s.sale_date > CURRENT_DATE ‐ INTERVAL '6' MONTH
09 ‐>
10 AND s.eur_value >= 10;
Datenbank: Sie führt keine Sortierung,
sondern ein Group-by auf vorsortierten
Daten durch.
Das Gute an Ausführungsplänen ist, dass
sie auch implizite Sortierungen explizit
anzeigen. Wenn man zum Beispiel zwei
Tabellen versehentlich mittels UNION
verbindet, zeigt der Ausführungsplan
auch die Operation zum Deduplizieren
der Ergebnisse an (Ausnahme: MySQL).
Wenn aber aufgrund der Daten ohnehin
keine Duplikate vorkommen können, und
damit ein UNION ALL genügt, verschwindet
diese Operation und damit auch der
entsprechende Speicherbedarf.
Ebenso wird bei einem DISTINCT eine
entsprechende Gruppier- oder Hash-Operation
angezeigt, die wiederum mit einem
gewissen Speicherbedarf einhergeht.
11 +‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
12 | id | table | type | key | key_len | rows | Extra |
13 +‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
14 | 1 | s | range | sale_date | 3 | 81858 | Using index condition; |
2
15
Using where ‚ |
16 | 1 | e | ALL | NULL | NULL | 10031 | Using where; |
17 Using join buffer 3 |
(Block Nested Loop) |
18 +‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
1 Durch das Voranstellen von explain vor die SQL-Abfrage wird der Ausführungsplan angezeigt.
2 »Using Where« in der Spalte »Extra« zeigt an, dass sich nicht alle Bedingungen über den Index
auflösen lassen. Aus dem Ausführungsplan alleine kann man aber nicht erkennen, welche Bedingungen
das sind.
3 MySQL verwendet einen Block-Nested-Loops-Join, der einen Speicherbedarf ähnlich einem Hash-
Join hat.
Antwortzeit [sec]
1.2
1.0
0.8
0.6
0.4
0.2
0.0
Filterprädikate
Umgekehrt gibt es auch Fälle, in denen
Datenbanken eine scheinbar notwendige
Sortieroperation unterlassen. So kann es
vorkommen, dass trotz Order-by-Klausel
in der SQL-Abfrage keine Sortieroperation
im Ausführungsplan erscheint. Dies
ist meist auf eine gewiefte Indizierung
zurückzuführen, die dafür sorgt, dass der
Index die Daten bereits in der gewünschten
Reihenfolge liefert. Diese Technik
wird oft mit Limit- oder Top-Klauseln
kombiniert und führt im Idealfall dazu,
dass der Ressourcenbedarf fast völlig von
der Tabellengröße entkoppelt ist. So kann
die Geschwindigkeit einer Abfrage, die
keine Where-Klausel hat, sogar unabhängig
von der Tabellengröße sein, wenn ein
passender Index im Spiel ist. Der SQL-
Abfrage selbst ist das nicht anzusehen.
Im Ausführungsplan erkennt man diese
Technik aber durch die fehlende Sortieroperation.
Fazit
Zugriffsprädikate
0.0
0 20 40 60 80 100
Tabellengröße [x3000 Zeilen]
Abbildung 2: Bei steigender Tabellengröße offenbart sich die ineffektive Indexnutzung.
1.2
1.0
0.8
0.6
0.4
0.2
Antwortzeit [sec]
Ausführungspläne gehören alleine wegen
der Fakten, die sie uns über die Datenbank
verraten, in das Repertoire aller
Datenbank-Adminstratoren und SQL-
Entwickler. Sie können helfen, die Ursache
von Performance-Problemen klar zu
erkennen und zu beheben. (jbr) n
Infos
[1] Ausführungspläne: [http:// use‐​the‐index‐​
luke. com/ de/ sql/ ausfuehrungsplaene]
Der Autor
Markus Winand hat sich als Autor, Trainer und
Coach darauf spezialisiert, Entwicklern bei Problemen
mit der SQL-Performance zu helfen. Er hat
das Buch „SQL Performance Explained“ veröffentlicht
und twittert seine besten Performance-
Tipps als @SQLPerfTips.
www.admin-magazin.de
Admin
Ausgabe 06-2012
91