it-swarm-eu.dev

Wie interpretieren Sie den EXPLAIN-Plan einer Abfrage?

Beim Versuch zu verstehen, wie eine SQL-Anweisung ausgeführt wird, wird manchmal empfohlen, den EXPLAIN-Plan zu lesen. Welchen Prozess sollte man durchlaufen, um einen Erklärungsplan zu interpretieren (sinnvoll zu machen)? Was sollte hervorstechen als "Oh, das funktioniert großartig?" versus "Oh nein, das stimmt nicht."

87
user290

Ich schaudere, wenn ich Kommentare sehe, dass vollständige Tabellen schlecht sind und der Indexzugriff gut ist. Vollständige Tabellensuchen, Indexbereichssuchen, schnelle vollständige Indexsuchen, verschachtelte Schleifen, Zusammenführungsverknüpfungen, Hashverknüpfungen usw. sind lediglich Zugriffsmechanismen, die vom Analysten verstanden und mit Kenntnissen über die Datenbankstruktur und den Zweck einer Abfrage in Verbindung gebracht werden müssen um zu einem sinnvollen Schluss zu kommen.

Ein vollständiger Scan ist einfach die effizienteste Methode zum Lesen eines großen Teils der Blöcke eines Datensegments (einer Tabelle oder einer Tabellen nter-) Partition), und obwohl dies häufig auf ein Leistungsproblem hindeutet, liegt dies nur im Kontext ob es sich um einen effizienten Mechanismus zur Erreichung der Ziele der Abfrage handelt. Als Data-Warehouse- und BI-Typ ist mein wichtigstes Warnungsflag für die Leistung eine indexbasierte Zugriffsmethode und eine verschachtelte Schleife.

Für den Mechanismus zum Lesen eines EXPLAIN-Plans ist die Oracle-Dokumentation eine gute Anleitung: --- (http://download.Oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm# PFGRF009

Lesen Sie auch das Handbuch zur Leistungsoptimierung durch.

Suchen Sie auch nach "Kardinalitäts-Feedback", einer Technik, mit der ein EXPLAIN-Plan verwendet werden kann, um die Schätzungen der Kardinalität in verschiedenen Phasen einer Abfrage mit den tatsächlichen Kardinalitäten zu vergleichen, die während der Ausführung festgestellt wurden. Wolfgang Breitling ist der Autor der Methode, glaube ich.

Unterm Strich also: Verstehen Sie die Zugriffsmechanismen. Verstehen Sie die Datenbank. Verstehen Sie die Absicht der Abfrage. Vermeiden Sie Faustregeln.

78
David Aldridge

Dieses Thema ist zu groß, um eine solche Frage zu beantworten. Nehmen Sie sich etwas Zeit zum Lesen von Oracle's Performance Tuning Guide

13
Tony Andrews

Die beiden folgenden Beispiele zeigen einen FULL-Scan und einen FAST-Scan mit einem INDEX.

Konzentrieren Sie sich am besten auf Ihre Kosten und Ihre Kardinalität. In den Beispielen reduziert die Verwendung des Index die Kosten für die Ausführung der Abfrage.

Es ist ein bisschen komplizierter (und ich habe kein 100% -Handle), aber im Grunde ist die Kosten eine Funktion der CPU und IO Kosten, und die Kardinalität ist die Anzahl der Zeilen Oracle erwartet zu analysieren. Beides zu reduzieren ist eine gute Sache.

Vergessen Sie nicht, dass die Kosten einer Abfrage von Ihrer Abfrage und dem Oracle-Optimierungsmodell (z. B. COST, CHOOSE usw.) sowie von der Häufigkeit der Ausführung Ihrer Statistiken abhängen.

Beispiel 1:

SCAN http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

Beispiel 2 mit Indizes:

INDEX http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

Und wie bereits vorgeschlagen, achten Sie auf TABLE SCAN. Sie können diese generell vermeiden.

5
Mark Nold

Suchen nach Dingen wie sequentiellen Scans kann etwas nützlich sein, aber die Realität liegt in den Zahlen ... es sei denn, die Zahlen sind nur Schätzungen! Was ist in der Regel weit nützlicher als das Betrachten eines Abfrageplans das Betrachten des tatsächlichen Plans Ausführung . In Postgres ist dies der Unterschied zwischen EXPLAIN und EXPLAIN ANALYZE. EXPLAIN ANALYZE führt die Abfrage tatsächlich aus und ruft für jeden Knoten echte Zeitinformationen ab. So können Sie sehen, was tatsächlich passiert, anstatt was der Planer denkt wird passieren. Oft werden Sie feststellen, dass ein sequentieller Scan überhaupt kein Problem darstellt, sondern etwas anderes in der Abfrage.

Der andere Schlüssel ist das Identifizieren des tatsächlichen teuren Schritts. Viele grafische Werkzeuge verwenden Pfeile unterschiedlicher Größe, um anzuzeigen, wie viel verschiedene Teile des Plans kosten. In diesem Fall müssen Sie nur nach Schritten suchen, bei denen dünne Pfeile kommen und ein dicker Pfeil geht. Wenn Sie keine grafische Benutzeroberfläche verwenden, müssen Sie die Zahlen überprüfen und feststellen, wo sie plötzlich viel größer werden. Mit ein wenig Übung wird es ziemlich einfach, die Problembereiche herauszufinden.

4
decibel

In solchen Fällen ist das Beste, was Sie tun können: ASKTOM . Insbesondere enthält seine Antwort auf diese Frage Links zum Online-Oracle-Dokument, in dem viele dieser Arten von Regeln erläutert werden.

Eine Sache, die Sie beachten sollten, ist, dass Erklärungspläne wirklich die besten Vermutungen sind.

Es ist eine gute Idee, sich mit sqlplus vertraut zu machen und mit dem Befehl AUTOTRACE zu experimentieren. Mit einigen harten Zahlen können Sie im Allgemeinen bessere Entscheidungen treffen.

Aber du solltest ASKTOM. Er weiß alles darüber :)

3
EvilTeach

Die Ausgabe des EXPLAIN gibt an, wie lange die einzelnen Schritte gedauert haben. Das erste ist, die Schritte zu finden, die lange gedauert haben, und zu verstehen, was sie bedeuten. Dinge wie ein sequentieller Scan zeigen Ihnen, dass Sie bessere Indizes benötigen - es ist meistens eine Frage der Recherche in Ihrer speziellen Datenbank und Erfahrung.

2
Tom Leys

Ein "Oh nein, das ist nicht richtig" hat oft die Form eines Tabellenscan. Tabellenscans verwenden keine speziellen Indizes und können dazu beitragen, alle nützlichen Informationen in den Speichercaches zu löschen. In postgreSQL sieht es beispielsweise so aus.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

Manchmal sind Tabellenscans ideal, wenn beispielsweise ein Index zum Abfragen der Zeilen verwendet wird. Dies ist jedoch eines der Muster, nach denen Sie scheinbar suchen.

2
convex hull

Grundsätzlich sehen Sie sich jede Operation an und prüfen, ob sie "sinnvoll" ist, wenn Sie wissen, wie sie funktionieren soll.

Wenn Sie beispielsweise zwei Tabellen, A und B, in den entsprechenden Spalten C und D (AC = BD) verbinden und Ihr Plan eine Clustered-Index-Suche (SQL Server-Begriff - der Oracle-Begriff ist nicht sicher) in der Tabelle anzeigt A, dann eine verschachtelte Schleife, die mit einer Reihe von Clustered-Index-Suchvorgängen in Tabelle B verknüpft ist, könnte ein Problem vorliegen. In diesem Szenario können Sie davon ausgehen, dass das Modul zwei Indexprüfungen (über die Indizes für die verbundenen Spalten) durchführt, gefolgt von einer Zusammenführungsverknüpfung. Weitere Untersuchungen könnten schlechte Statistiken ergeben, die das Optimierungsprogramm veranlassen, dieses Verknüpfungsmuster oder einen Index auszuwählen, der tatsächlich nicht vorhanden ist.

2
Jonathan Rupp

sehen Sie sich den Prozentsatz der Zeit an, die in den einzelnen Unterabschnitten des Plans verbracht wurde, und überlegen Sie, was die Engine leistet. Wenn Sie beispielsweise eine Tabelle scannen, sollten Sie erwägen, einen Index für die Felder zu erstellen, nach denen gesucht wird

1
Steven A. Lowe

Ich suche hauptsächlich nach Index- oder Tabellenscans. In der Regel fehlt mir ein Index für eine wichtige Spalte in der where-Anweisung oder der join-Anweisung.

From http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :

Wenn Sie in einem Ausführungsplan eines der folgenden Elemente sehen, sollten Sie diese als Warnzeichen betrachten und sie auf potenzielle Leistungsprobleme untersuchen. Jeder von ihnen ist aus Sicht der Leistung weniger als ideal.

* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 

Es ist nicht immer möglich, diese zu vermeiden. Je mehr Sie sie jedoch vermeiden können, desto schneller ist die Abfrageleistung.

1
dpollock