Oracle
 sql >> Datenbank >  >> RDS >> Oracle

Verstehen der Ergebnisse von Execute Explain Plan in Oracle SQL Developer

Die Ausgabe von EXPLAIN PLAN ist eine Debug-Ausgabe des Abfrageoptimierers von Oracle. COST ist die endgültige Ausgabe des kostenbasierten Optimierers (CBO), dessen Zweck darin besteht, auszuwählen, welcher der vielen verschiedenen möglichen Pläne zum Ausführen der Abfrage verwendet werden soll. Der CBO berechnet die relativen Kosten für jeden Plan und wählt dann den Plan mit den niedrigsten Kosten aus.

(Anmerkung:In einigen Fällen hat der CBO nicht genug Zeit, um alle möglichen Pläne zu bewerten; in diesen Fällen wählt er einfach den Plan mit den niedrigsten gefundenen Kosten aus)

Im Allgemeinen ist einer der größten Beiträge zu einer langsamen Abfrage die Anzahl der Zeilen, die gelesen werden, um die Abfrage zu bedienen (Blöcke, um genauer zu sein), sodass die Kosten teilweise basieren über die Anzahl der Zeilen müssen die Schätzungen des Optimierers gelesen werden.

Nehmen wir zum Beispiel an, Sie haben die folgende Abfrage:

SELECT emp_id FROM employees WHERE months_of_service = 6;

(Die months_of_service Spalte hat eine NOT NULL-Einschränkung und einen gewöhnlichen Index.)

Es gibt zwei grundlegende Pläne, die der Optimierer hier wählen könnte:

  • Plan 1:Lesen Sie alle Zeilen aus der Tabelle "Mitarbeiter" und prüfen Sie für jede, ob das Prädikat wahr ist (months_of_service=6 ).
  • Plan 2:Lesen Sie den Index, wobei months_of_service=6 (Dies führt zu einer Reihe von ROWIDs), und greife dann basierend auf den zurückgegebenen ROWIDs auf die Tabelle zu.

Stellen wir uns vor, die Tabelle „Mitarbeiter“ hat 1.000.000 (1 Million) Zeilen. Stellen wir uns weiter vor, dass die Werte für month_of_service von 1 bis 12 reichen und aus irgendeinem Grund ziemlich gleichmäßig verteilt sind.

Die Kosten für Plan 1 , was einen VOLLSTÄNDIGEN SCAN beinhaltet, sind die Kosten für das Lesen aller Zeilen in der Tabelle „Employees“, was ungefähr 1.000.000 entspricht; Da Oracle die Blöcke jedoch häufig mit Multiblock-Lesevorgängen lesen kann, sind die tatsächlichen Kosten geringer (je nachdem, wie Ihre Datenbank eingerichtet ist) - z. Stellen wir uns vor, die Anzahl der Multiblock-Lesevorgänge beträgt 10 - die berechneten Kosten für den vollständigen Scan betragen 1.000.000 / 10; Gesamtkosten =100.000.

Die Kosten für Plan 2 , die einen INDEX RANGE SCAN und eine Tabellensuche nach ROWID beinhaltet, sind die Kosten für das Scannen des Index plus die Kosten für den Zugriff auf die Tabelle nach ROWID. Ich werde nicht darauf eingehen, wie Indexbereichsscans kosten, aber stellen wir uns vor, die Kosten für den Indexbereichsscan betragen 1 pro Zeile. wir erwarten, in 1 von 12 Fällen eine Übereinstimmung zu finden, also betragen die Kosten für den Index-Scan 1.000.000 / 12 =83.333; plus die Kosten für den Zugriff auf die Tabelle (angenommen, 1 Blocklesevorgang pro Zugriff, wir können hier keine Multiblock-Lesevorgänge verwenden) =83.333; Gesamtkosten =166.666.

Wie Sie sehen können, sind die Kosten für Plan 1 (vollständiger Scan) GERINGER als die Kosten für Plan 2 (Index-Scan + Zugriff nach Zeilen-ID) – was bedeutet, dass der CBO den VOLLSTÄNDIGEN Scan wählen würde.

Wenn die hier vom Optimierer getroffenen Annahmen wahr sind, dann ist Plan 1 tatsächlich vorzuziehen und viel effizienter als Plan 2 – was den Mythos widerlegt, dass VOLLSTÄNDIGE Scans „immer schlecht“ sind.

Die Ergebnisse wären ganz anders, wenn das Ziel des Optimierers FIRST_ROWS(n) anstelle von ALL_ROWS wäre – in diesem Fall würde der Optimierer Plan 2 bevorzugen, weil er oft die ersten Zeilen schneller zurückgibt, auf Kosten einer weniger effizienten Ausführung der gesamten Abfrage .