RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

Index-Nutzung

Eine andere Fehlinterpretation von Ausführungsplänen hat mit der Verwendung von Indizes zu tun. Hier herrscht oft die Vorstellung, dass ein Index die Ausführung prinzipiell beschleunigt. Das ist aber nur die halbe Wahrheit. Es gibt Fälle, in denen ein Index die Ausführung tatsächlich bremsen kann. Das sind vor allem Abfragen, die einen verhältnismäßig großen Teil einer Tabelle lesen. Ein Indexzugriff würde dabei sehr viele Lesezugriffe auf kleine Datenblöcke verursachen. Wenn die Datenbank die Tabelle stattdessen vollständig liest, kann sie größere Datenblöcke auf einmal anfordern und dadurch die Anzahl der Leseoperationen verringern. Das kann einen Performance-Vorteil bringen, weil bei Speichersystemen neben dem Durchsatz auch die IOPS (Input/Output Operations per Second) begrenzt sind. Für die Entscheidung, ob es hilft oder schadet, einen Index zu nutzen, wird übrigens der Cost- Wert verwendet: Die Datenbank bewertet damit beide Ausführungsplan-Varianten und wählt letztendlich den mit dem besseren Cost-Wert.

Aus einem Ausführungsplan kann man aber nicht nur ablesen, welcher Index benutzt wird, sondern auch etwas über die Effektivität des Indexzugriffes erfahren. Die hängt hauptsächlich davon ab, welche Teile der Where-Klausel durch den Index abgedeckt werden. Das kann man bei manchen Datenbanken anhand der sogenannten Filterprädikate direkt aus dem Ausführungsplan ablesen. Taucht ein solches Filterprädikat beim Tabellenzugriff auf, kann das ein Hinweis sein, dass diese Spalte im Index fehlt (Beispiel 1 und Beispiel 3).

Beispiel 3: Ausführungsplan einer PostgreSQL-Datenbank

 

Durch das Voranstellen von explain vor die SQL-Abfrage wird der Ausführungsplan angezeigt.

Die Cost-Werte werden für jeden Teil-Baum des Ausführungsplanes angezeigt. PostgreSQL zeigt dabei jeweils zwei Werte an: zuerst die Setupkosten, dann die Gesamtkosten.

Das Filterprädikat beim Indexzugriff ist bei PostgreSQL ein Hinweis, dass die Spalte EUR_VALUE nicht im Index SALE_DATE vorhanden ist.

Durch die rows- und width-Werte beim Hash-Zweig der Join-Operation kann man auf den Speicherbedarf schließen. Dadurch wird auch deutlich, dass der Speicherbedarf nicht nur von den Zeilen, sondern auch von den selektierten Spalten – der Zeilenlänge – abhängig ist. Selektiert man weniger Spalten, reduziert sich der Speicherbedarf.

Bei einem Indexzugriff können Filterprädikate auch ein Zeichen für eine falsche Spaltenreihenfolge sein (Beispiel 2). Nur wenn als Zugriffsprädikat die Werte »access« oder »seek predicate« angezeigt werden, nutzt die Abfrage den Index optimal aus.

Beispiel 2: SQL Server-Ausführungsplan erklärt

Hier kann man sich über die Schaltfläche »Display Estimated Execution Plan« den Ausführungsplan anzeigen lassen. Bewegt man den Mauszeiger über eine Operation, öffnet sich ein Tool-Tip mit zusätzlichen Informationen. Der Cost-Wert der einzelnen Operation wird gleich dreimal angezeigt: zuerst aufgeteilt nach I/O- und CPU-Cost, dann die Gesamtkosten. Zuletzt wird auch der Cost-Wert des gesamten Teil-Baumes angezeigt. Die Gesamtkosten findet man im Tool-Tip auf oberster Ebene. Das Filterprädikat ( »Predicate« ) ist ein Hinweis, dass die Spalte »EUR_VALUE« nicht an einer geeigneten Index-Position für eine effiziente Nutzung steht. Das Zugriffsprädikat ( »YSeek Predicate« ) beim Indexzugriff zeigt, dass der Index nur für die Bedingung auf »SALE_DATE« effizient genutzt wird.

Filter- und Zugriffsprädikate können sinngemäß auch bei der Suche in einem gedruckten Telefonbuch vorkommen, wenn man zum Beispiel nur den Nachnamen und die Anschrift der gesuchten Person kennt. Dabei ist der erste Schritt, etwa alle Einträge für "Müller" zu finden, sehr rasch erledigt. Aufgrund der Sortierung des Telefonbuches kann man sich durch Vor- und Zurückblättern schnell an "Müller" annähern. Genau genommen führt man dabei eine binäre Suche durch, deren Aufwand nur logarithmisch mit der Größe des Telefonbuches wächst. Anders gesagt, wenn das Telefonbuch zehnmal so groß ist, dauert die Suche deswegen nicht auch gleich zehnmal so lange.

In einer Datenbank wäre die Bedingung NACHNAME='MÜLLER' daher ein Zugriffsprädikat. Hat man die "Müllers" gefunden, bleibt noch die Eingrenzung mit der bekannten Adresse. Ohne den Vornamen zu kennen, kann man aber die Sortierung des Telefonbuches nicht weiter nutzen. Es bleibt einem also nichts anderes übrig, als alle "Müllers" durchzugehen. In einer Datenbank wäre diese Bedingung daher ein Filterprädikat. Die Suchdauer steigt linear mit der Anzahl der "Müllers."

Filtern dauert viel länger

Der Unterschied zwischen Zugriffs- und Filterprädikaten wird häufig unterschätzt, kann aber durchaus beachtlich sein. Abbildung 2 stellt den Performance-Unterschied dar. Im Idealfall – wenn zum Beispiel nur Zugriffsprädikate verwendet werden – kann die Geschwindigkeit auch bei einer stark wachsenden Tabelle nahezu konstant bleiben (grün dargestellt). Je mehr Filterprädikate verwendet werden, desto größer wird der Einfluss der Tabellengröße auf die Geschwindigkeit (rot dargestellt). Anders ausgedrückt kann man durch die Filter- und Zugriffsprädikate eine Prognose über die Geschwindigkeit bei wachsendem Datenvolumen anstellen und dadurch Probleme im Vorhinein erkennen. Die Ursache des eklatanten Performance-Unterschiedes in der Abbildung ist übrigens, dass die zweite und dritte Spalte im Index vertauscht wurden.

Abbildung 2: Bei steigender Tabellengröße offenbart sich die ineffektive Indexnutzung.

Bei der Indizierung einer Datenbank muss man aber unbedingt ganzheitlich vorgehen. Insbesondere das Ändern der Spaltenreihenfolge ist gefährlich, weil es den Index für andere Abfragen unbrauchbar machen kann. Indexänderungen muss man daher ausgiebig testen, sorgfältig planen und natürlich mit dem Applikationshersteller abklären.

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.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023