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. Siehe ALTER DATABASE-Anweisung.

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. Siehe optimization_goal-Option.

Die meisten Befehle 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.

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. Siehe optimization_level-Option.

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.