von Markus Winand.

Auswirkungen der Systemlast


Die Überlegungen beim Anlegen eines mehrspaltigen Indexes enden meist, sobald der Index für die gewünschte Abfrage benutzt wird. Der Optimizer verwendet ihn aber nicht, weil er für die Abfrage „richtig“ ist. Es genügt, dass der Indexzugriff besser als ein Full-Table-Scan ist. Das heißt keines­wegs, dass der Index die Abfrage optimal unterstützt.

Das vorherige Beispiel hat gezeigt, wie schwierig es ist, eine falsche Spal­ten­reihen­folge im Ausführungsplan zu erkennen. Die Prädikatsinformationen sind oft so gut versteckt, dass man schon gezielt danach suchen muss, um zu wissen, ob der Index optimal verwendet wird.

Im SQL Server Management Studio werden die Prädikatsinformationen zum Beispiel nur als Tool-Tip angezeigt, wenn man den Mauszeiger auf eine Index-Operation bewegt („hover“) – auch auf dieser Webseite. Im folgenden Ausführungsplan wird der Index SCALE_SLOW verwendet. Daher scheint die Bedingung auf ID2 als Filterprädikat („Predicate“, ohne Seek) auf.

Bei MySQL und PostgreSQL ist es noch mühsamer, herausfinden, welche Bedingungen Zugriffs- oder Filterprädikate sind. Die Details finden sich in Anhang A.

Die Prädikatstypen können im Ausführungsplan noch so unscheinbar sein, sie haben eine enorme Auswirkung auf die Performance – vor allem, wenn das System wächst. Es wächst nämlich nicht nur das Datenvolumen, wie im vorigen Abschnitt dargestellt, sondern hoffentlich auch die Zugriffsrate. Sie ist natürlich auch eine Variable im Skalierungsverhalten einer Datenbank.

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 folgende Abbildung zeigt daher die Antwortzeit als Funktion der Zugriffsrate – das Datenvolumen bleibt konstant. Dafür wurde die Abfrage des vorherigen Abschnittes mit dem maximalen Datenvolumen verwendet. Das heißt, der letzte Punkt aus Abbildung 3.2 entspricht dem ersten Punkt in diesem Chart.

Abbildung 3.4 Antwortzeit als Funktion der Systemlast

Die gestrichelte Linie zeigt die Antwortzeit mit dem Index SCALE_SLOW. Bei 25 gleichzeitigen Abfragen steigt die Antwortzeit auf 32 Sekunden. Im Vergleich zur Geschwindigkeit ohne Hintergrundaktivität – wie es zum Beispiel in einer Entwicklungsumgebung sein könnte – dauert die Abfrage 30-mal so lange. Selbst wenn man den vollen Datenbestand in der Entwicklungsumgebung hat, kann die Abfrage im Produktionssystem immer noch um Faktoren langsamer sein.

Die zweite Linie zeigt den Verlauf der Antwortzeit mit dem Index SCALE_FAST – also ohne Filterprädikat. Dadurch bleibt die Antwortzeit stets unter 2 Sekunden – selbst wenn 25 Abfragen gleichzeitig laufen.

Beachte

Das sorgfältige Lesen des Ausführungsplanes gibt mehr Sicherheit als oberflächliche Tests.

Ein voller Stresstest ist dennoch wertvoll, aber viel aufwendiger.

Auffällige Antwortzeiten werden während der Entwicklung oft „auf die leichte Schulter genommen“. Meistens, weil man von der „viel stärkeren Produktionshardware“ bessere Performance erwartet. Das Produktions­system ist aber häufig komplexer – dadurch können sich zum Beispiel Latenzen akkumulieren, die in der Entwicklungsumgebung nicht auf­tre­ten. Selbst wenn das Testsystem produktionsäquivalent ist, hat man in der Produktion eine andere Hintergrundlast und damit andere Antwortzeiten. Im nächsten Abschnitt werden wir sehen, dass es ganz generell keine gute Idee ist, von „größerer Hardware“ schnellere Antworten zu erwarten.

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