So funktioniert der Optimierer

Die Rolle des Optimierers besteht darin, einen effizienten Weg zum Ausführen von SQL-Anweisungen zu finden. Dazu muss der Optimierer einen Ausführungsplan für eine Abfrage festlegen. Dieser Plan umfasst Entscheidungen über die Zugriffsreihenfolge für Tabellen, die in der Abfrage referenziert werden, über die Join-Operatoren und Zugriffsmethoden für jede Tabelle sowie darüber, ob materialisierte Ansichten, die nicht in der Abfrage referenziert werden, zur Berechnung von Teilen der Abfrage benutzt werden können. Der Optimierer versucht, den besten Plan für die Ausführung der Abfrage während der Join-Enumerationsphase auszuwählen, während der mögliche Zugriffspläne für eine Abfrage generiert und die Kosten berechnet werden. Der beste Zugriffsplan ist derjenige, der nach Einschätzung des Optimierers die gewünschte Ergebnismenge in der kürzesten Zeit und mit den geringsten Kosten liefern wird. Der Optimierer ermittelt die Kosten jeder bei der Enumeration gefundenen Strategie, indem er die Anzahl der erforderlichen Lese- und Schreibvorgänge schätzt.

In Interactive SQL können Sie den besten Zugriffsplan zum Ausführen einer Abfrage anzeigen, indem Sie auf Extras » Plananzeige klicken.

Kosten für die Rückgabe der ersten Zeile minimieren

Der Optimierer verwendet ein generisches Kostenmodell für Festplattenzugriffe, um die relativen Performance-Unterschiede zwischen wahlfreien und sequenziellen Abrufen aus der Datenbankdatei zu unterscheiden. Eine Datenbank kann auch mithilfe einer ALTER DATABASE-Anweisung für eine bestimmte Hardware-Konfiguration angepasst werden.

Standardmäßig wird die Abfrageverarbeitung so optimiert, dass die komplette Ergebnismenge schnell zurückgegeben wird. Mit der Option "optimization_goal" können Sie das Standardverhalten ändern, um die Kosten für die schnelle Rückgabe der ersten Zeile zu minimieren. Wenn die Option auf "First-row" gesetzt ist, bevorzugt der Optimierer einen Zugriffsplan, der die Zeitspanne zum Abruf der ersten Zeile der Ergebnismenge reduzieren soll, worunter möglicherweise die Gesamtabrufzeit leidet.

Semantisch äquivalente Syntax verwenden

Die meisten Anweisungen können unter Verwendung der SQL-Sprache auf viele Arten ausgedrückt werden. Diese Ausdrücke sind semantisch gleichwertig, wodurch sie dieselbe Aufgabe durchführen, aber sie können sich in ihrer Syntax grundlegend unterscheiden. Mit wenigen Ausnahmen entwirft der Optimierer einen geeigneten Zugriffsplan, der nur auf der Semantik der einzelnen Anweisungen aufbaut.

Syntaktische Unterschiede haben gewöhnlich keine Auswirkungen, auch wenn sie substanziell erscheinen mögen. So haben zum Beispiel Unterschiede in der Reihenfolge von Prädikaten, Tabellen und Attributen in der Abfrage keine Auswirkungen auf die Auswahl im Zugriffsplan. Auch wird der Optimierer nicht davon beeinflusst, ob eine Abfrage eine nicht materialisierte Ansicht enthält.

Kosten von Optimierungsabfragen vermindern

Idealerweise würde der Optimierer den effizientesten Plan, der zur Verfügung steht, auswählen, doch das ist oft nicht durchführbar. Bei einer komplizierten Abfrage gibt es zahlreiche mögliche Lösungen.

Wie effizient der Optimierer auch sein mag, so benötigt doch das Analysieren der einzelnen Optionen Zeit und Ressourcen. Der Optimierer vergleicht die Kosten weiterer Optimierungen mit den Kosten, die ein Ausführen des bisher besten Plans verursachen würde. Wenn ein Plan mit relativ geringen Kosten entwickelt worden ist, stoppt der Optimierer und ermöglicht es, dass dieser Plan ausgeführt wird. Eine weitere Optimierung könnte mehr Ressourcen als das Ausführen eines bereits gefundenen Zugriffsplans verbrauchen. Sie können kontrollieren, wie viel Aufwand der Optimierer betreibt, indem Sie für die Option "optimization_level" einen hohen Wert festlegen.

Der Optimierer arbeitet länger bei kostenträchtigen und komplexen Abfragen oder wenn eine hohe Optimierungsstufe eingestellt ist. Bei sehr kostenträchtigen Abfragen dauert die Ausführung möglicherweise so lange, dass eine Verzögerung feststellbar ist.

Siehe auch

Optimiererschätzungen und -statistiken
Quellen der Selektivitätsschätzung
Plan-Caching
Caching von Unterabfragen und Funktionen

Kommentieren Sie diese Seite in DocCommentXchange.