QueryPerformanceCounter

 

 

Diese API-Funktion ist die von Windows zur Verfügung gestellte Meßmethode mit der höchsten zeitlichen Auflösung, die systemabhängig bis in den Nanosekundenbereich reicht.


In der Beispiel-DB findet sich eine Kapselung der API-Funktion in eine im Code bequem verwendbare Routine, die auch die systematischen Tücken, die beim Messen grundsätzlich zu beachten sind, umschifft.

 

Prozeduraufrufzähler

 

 

Die Funktion dient dazu, festzustellen, wie Funktionsaufrufe innerhalb von Abfragen von Jet gehandhabt werden. Durch den Sleep-Parameter kann man die Auswirkungen länger dauernder Aufrufe auf den Aufbau der Bildschirmanzeige des Resultsets beobachten.

 

JetShowPlan

 

 

Durch diesen Registry-Schlüssel wird eine Protokollausgabe von Jet erzeugt. Man kann dort nachvollziehen, wie eine Abfrage von Jet im Detail ausgeführt wurde.
Die Ausgabe entsteht in Form einer Textdatei, die den Namen showplan.out hat. Sie befindet sich im allgemeinen im Ordner Eigene Dateien oder im Ordner,  in dem sich die DB befindet. Sollte sich die Datei nicht gleich finden lassen, läßt man einfach eine Windows-Suche mit dem Dateinamen laufen.
Da neue Einträge am Ende angefügt werden, und die Ausgabe bei jedem Ausführen einer Abfrage erfolgt, wird die Datei mit der Zeit sehr groß. Man sollte also den Showplan nur bei Bedarf einschalten oder die Ausgabedateien gelegentlich löschen.
Zur Bedeutung der Ausgaben gibt es leider keine einfach zugängliche  Dokumentation, was den Wert erheblich einschränkt. Dennoch kann man ein paar grundlegende Dinge festhalten.

 

Gute Ergebnisse

 

Ein optimales Ergebnis bei Bedingungen mit Operatoren ist der Eintrag Using Rushmore. Die Rushmore-Technologie ist eine besonders effiziente Art, die Informationen eines Index zu nutzen.
Zufriedenstellend sind Angaben wie Inner Join, Outer Join, Semi Join, Merge Join zu den zur Join-Berechnung verwendeten Algorithmen.
Einige Beispielausgaben:

 

 

Schlechte Ergebnisse

 

 

Ein schlechtes Ergebnis ist insbesondere „using Xprod join“, da der Kreuzprodukt-Algorithmus der mit Abstand langsamste Join-Algorithmus ist. Er ist aber unvermeidlich, wenn die Join-Felder nicht indiziert sind oder ungünstige Kriterien eine Indexnutzung verhindern.

 

 

Anmerkungen zu den Join-Typen
Neben der bekannten logischen Kategorisierung von Joins wie Inner Join, Left/Right Outer Join, Full Join, Semi Join, Natural Join gibt es auch ähnlich benannte Algorithmen, die beschreiben, mit welchen Anweisungen ein Join durchzuführen ist. Mit diesen hat man in der Regel nichts zu tun, da sie ja Bestandteil des DBMS sind, ebenso wie die Auswahl des anhand der Datenkonstellation bestgeeigneten Algorithmus.
Join-Algorithmen ähneln einer Mischung aus Such- und Sortieralgorithmen, und wie dort gibt es mehr oder weniger effiziente Vorgehensweisen, wobei die beste Wahl noch von der Datenlage (Indizierung, statistische Verteilung) abhängt.

 

Übliche Algorithmen sind z. B.

 

Das schlimmste Ergebnis, das produziert werden kann, ist ein X prod join in der Ausgabe. Es bedeutet, daß das kartesische Produkt aller Datensätze gebildet wurde, um dann alle auszusortieren, die nicht der Join-Bedingung entsprechen. Dieses Ergebnis bekommt man zum Beispiel beim Join über nichtindizierte Felder oder bei Theta-Joins, also solchen, die als Vergleichsoperator für tabellenübergreifende Felder etwas anderes als = benutzen.
Wenn es geht, sollte man solche Konstrukte vermeiden.
Einen Einfluß auf die Wahl des Algorithmus, außer durch Indizierung den Boden zu bereiten, hat man sowieso nicht; es ist also müßig, sich hier allzu viele Gedanken zu machen.

 

Abfragemessung über Recordset:

 

Wenn man sich nicht mit der Stoppuhr an den Bildschirm setzen will, ist es erforderlich, die Ausführung einer Abfrage per VBA zu kontrollieren. Hierzu wird man ein auf der Abfrage basierendes Recordset erstellen. Um dabei sinnvolle Ergebnisse zu erhalten, sind einige Eigenheiten zu beachten.
Die Zeit für das reine Erstellen des Recordet-Objekts ist nicht aussagekräftig, daher ist ein MoveLast auszuführen.
Um den Einfluß von Berechnungen zu beurteilen, ist  zusätzlich ein satzweises Lesen des berechneten Feldwertes nötig, da Jet Werte erst bei Bedarf errechnet.
Für sehr präzise Ergebnisse sollte immer auch der Overhead einer Messung herausgerechnet werden, also die Zeit, die für die reine Verwaltung eines Recordsets benötigt wird. Die im folgenden aufgeführten Beispiele sind in der Auswirkung so drastisch (mehrere hundert bis zehntausend Prozent), daß man von solchen Feinheiten absehen kann.
Für eigene Experimente sei noch darauf hingewiesen, daß die bei mit Meßtechniken weniger Erfahrenen beliebte Methode, den Prüfcode in einer Schleife mehrmals ablaufen zu lassen, um eine bessere zeitliche Auflösung zu bekommen, für Abfragemessungen nicht sinnvoll einsetzbar ist, da Geschwindigkeitsunterschiede hier in der Regel auf Indexnutzung basieren und daher eine nichtlineare Zeitkomplexität aufweisen.
Eine Messung über hunderttausend Datensätze läßt sich im allgemeinen nicht durch eine Messung über hundert Datensätze, die in einer Schleife tausendmal ausgeführt wird, simulieren.

 

Bedeutung der Prozentangaben

 

Bei vielen Beispielen sind Angaben, um wieviel Prozent die Geschwindigkeit bei Optimierung steigt. Diese Angaben sind kein konstantes Verhältnis, sondern hängen von Struktur und Menge der Daten ab. Das liegt daran, daß die vom DB-System eingesetzten Algorithmen im allgemeinen keinen proportionalen Zeitzuwachs aufweisen.
Eine Vorgehensweise, die bei wenigen Daten nur anderthalb mal so schnell ist wie die zum Vergleich herangezogene Methode, kann bei größeren Datenmengen durchaus zehn- oder hundertmal so schnell sein. Die im Text angegebenen Werte sind in genau dieser Form außer mit dem Datenbestand, mit dem sie erzeugt worden sind, nicht exakt reproduzierbar. Man verstehe sie daher als Hinweis, bei welcher Konstruktion die bessere Laufzeit zu erwarten ist.

 

Meßplattform

 

Alle Tests wurden mit Access XP auf Windows XP Professional vorgenommen.
Die meisten Ratschläge gelten im wesentlichen – zum Teil sogar verstärkt –, für alle Access-Versionen, bei anderen Versionen kann es aber in den Auswirkungen zu mehr oder weniger starken Unterschieden kommen.
Etliche Ratschläge, die einfach auf allgemeinen logischen Grundsätzen basieren, sind sogar in ähnlicher Weise auf andere DB-Systeme übertragbar, hier sind die Abweichungen aber naturgemäß groß, da andere Systeme andere Abfrageoptimierer haben und andere SQL-Syntaxvarianten unterstützen.