Performanceanalyse mithilfe des grafischen Plans mit Statistik

Sie können Datenbankoptionen und andere globale Einstellungen anzeigen, die sich auf die Abfrageausführung bei den Stamm-Operatorknoten auswirken.

Die Selektivität eines Prädikats (bedingter Ausdruck) ist der Prozentsatz von Zeilen, die die Bedingung erfüllen. Die geschätzte Selektivität von Prädikaten liefert die Informationen, auf denen der Optimierer seine Kostenschätzungen aufbaut. Eine genaue Selektivitätsschätzung ist für die ordnungsgemäße Funktion des Optimierers ausschlaggebend. Wenn der Optimierer beispielsweise versehentlich ein Prädikat für höchst selektiv hält (z.B. eine Selektivität von 5 %), das Prädikat jedoch sehr viel weniger selektiv ist (z.B. 50 %), dann kann die Performance darunter leiden. Auch wenn Selektivitätsschätzungen nicht immer präzise sind, kann ein außergewöhnlich großer Fehler auf ein Problem hinweisen.

Wenn Sie feststellen, dass die Selektivitätsinformationen für einen Schlüsselabschnitt Ihrer Abfrage nicht stimmen, können Sie möglicherweise CREATE STATISTICS verwenden, um eine neue Reihe von Statistiken für die Spalte(n) zu generieren. In seltenen Fällen können Sie explizite Selektivitätsschätzungen vorgeben, obwohl dieses Vorgehen zu Problemen führen kann, wenn die Statistiken später aktualisiert werden.

Selektivitätsstatistiken werden nicht angezeigt, wenn die Abfrage als eine Bypass-Abfrage festgelegt ist.

Indikatoren für eine schlechte Selektivität treten an folgenden Stellen auf:

RowsReturned, tatsächlich und geschätzt RowsReturned ist die Anzahl der Zeilen in der Ergebnismenge. Die RowsReturned-Statistik wird in der Tabelle für den Stammknoten an der Spitze der Struktur angezeigt. Wenn die geschätzte Zeilenanzahl deutlich von der tatsächlichen Zeilenanzahl abweicht, ist möglicherweise die Selektivität von den diesem Knoten oder dieser Unterstruktur zugeordneten Prädikaten falsch.
Prädikat-Selektivität, tatsächlich und geschätzt Suchen Sie nach dem Subheader Prädikate, um die Prädikat-Selektivitäten einzusehen.
Wenn das Prädikat für eine Basisspalte gilt, für die kein Histogramm vorhanden ist, kann das Problem eventuell behoben werden, indem durch die Ausführung einer CREATE STATISTICS-Anweisung ein Histogramm erstellt wird.

Wenn der Selektivitätsfehler weiterhin Probleme bereitet, könnten Sie eine Benutzerselektivitätsschätzung mit dem Prädikat im Abfragetext angeben.
Quelle der Schätzung Die Quelle der Selektivitätsschätzungen ist ebenso unter dem Prädikat-Subheader im Fensterausschnitt Statistik aufgelistet.
Wenn die Quelle einer Prädikat-Selektivitätsschätzung Annahme (Guess) ist, hat der Optimierer keine verwertbaren Informationen, um die Filtermerkmale dieses Prädikats zu ermitteln, was möglicherweise auf ein Problem hinweist (wie z.B. ein fehlendes Histogramm). Falls die Quelle für die Schätzung Index und die Selektivitätsschätzung falsch ist, kann das Problem durch einen unausgeglichenen Index verursacht sein. In so einem Fall kann es vorteilhaft sein, den Index mit der Anweisung REORGANIZE TABLE zu defragmentieren.

Wenn die Anzahl der Cache-Lesevorgänge (CacheRead) und die der Cachetreffer (CacheHits) gleich sind, befinden sich alle Objekte, die bei dieser SQL-Anweisung verarbeitet werden, im Cache. Wenn es mehr Cache-Lesevorgänge als Cachetreffer gibt, zeigt dies, dass der Datenbankserver Tabellen- oder Indexseiten vom Plattenspeicher liest, weil sie sich noch nicht im Cache des Datenbankservers befinden. Unter bestimmten Umständen, z.B. bei Hash-Joins, ist dies zu erwarten. In anderen Fällen, wie z.B. bei Nested-Loops-Joins, kann ein schlechtes Cachetreffer-Verhältnis darauf hinweisen, dass nicht genügend Cache (Pufferpool) vorhanden ist, um die Abfrage effizient auszuführen. In diesem Fall ist es sinnvoll, die Cachegröße des Datenbankservers zu erhöhen.

Häufig ist auch mit Abfrageausführungsplänen nicht eindeutig ersichtlich, ob die Performance durch Indizes gesteigert werden könnte. Einige der auf Scans basierenden Abfragevorgänge, die in SQL Anywhere eingesetzt werden, bieten eine hervorragende Performance für viele Abfragen, ohne dass Indizes verwendet werden.

Die tatsächlichen und geschätzten Werte Runtime und FirstRowRunTime sind in den Stammknoten-Statistiken enthalten. Nur RunTime wird im Abschnitt Verzweigungsstatistiken angezeigt, wenn für diesen Knoten ein Wert vorhanden ist.

Die Interpretation von RunTime hängt vom Statistikabschnitt ab, in dem der Wert angezeigt wird. In Knotenstatistiken ist RunTime die kumulative Zeit, die der Operator für das Ausführen nur dieses Knotens aufgewendet hat. In Verzweigungsstatistiken stellt RunTime die Gesamt-Ausführungszeit dar, die der Operator für das Ausführen der Unterstruktur unmittelbar unterhalb dieses Knotens aufgewendet hat. Daher sind RunTime und FirstRowRunTime bei den meisten Operatoren voneinander unabhängige Metriken, die separat analysiert werden sollten:

FirstRowRunTime ist die Zeit, die benötigt wird, um die erste Zeile des Zwischenergebnisses von diesem Knoten zu liefern.

Wenn RunTime eines Knotens für einen Table-Scan oder einen Index-Scan höher als erwartet ist, können Sie die Performance möglicherweise verbessern, indem Sie die REORGANIZE TABLE-Anweisung ausführen. Sie können die Systemprozeduren "sa_table_fragmentation()" und "sa_index_density()" verwenden, um festzustellen, ob die Tabelle oder der Index fragmentiert ist.

Performanceanalyse mithilfe des grafischen Plans mit Statistik

Abfrageausführungsprobleme erkennen

Selektivitätsperformance überprüfen

Cache-Performance überprüfen

Ineffiziente Indizes identifizieren

Probleme mit der Datenfragmentierung identifizieren

Siehe auch