Jonathan Lewis hat in den letzten Tagen zwei Artikel veröffentlicht, die sich mit den Möglichkeiten der Kombination von Indizes beim Zugriff beschäftigen. Üblicherweise entscheidet sich der Optimizer bekanntlich für einen der existierenden Indizes, der ihm am besten geeignet erscheint, um einen selektiven Zugriff zu gewährleisten und verwendet weitere Bedingungen als Filter für die über den Index ermittelte Menge von Datensätzen:
- Conditional SQL – 4: beschäftigt sich mit einem besonderen Fall konditionaler Ausführungspläne, bei denen abhängig vom Vorliegen eines Bindewerts ein gefiltertes Ergebnis oder alle Datensätze geliefert werden sollen (eine Standardvariante dazu wäre z.B.: where t1.n1 = nvl(:n1,t1.n1); wenn ein Bindewert vorliegt, wird mit diesem verglichen, sonst erfolgt der - immer true liefernde - Vergleich der Spalte mit sich selbst). Im speziellen Fall wurden zwei über index concatenation verknüpfbare Bedingungen mit einer dritten Bedingung (LENGTH ( :b7) IS NULL) OR-verknüpft, was den Optimizer dann zum full table scan übergehen lässt. Dieses Verhalten ändert sich auch nicht, wenn man auf die dubiose LENGTH-Verwendung verzichtet. Insgesamt bleibt festzuhalten: "the optimizer’s ability to introduce concatenation is limited".
- Index Hash: zeigt, dass das costing für HASH JOINS, bei denen die Inhalte zweier Indizes einer Tabelle verknüpft werden (um auf den teureren Zugriff auf eine relativ breite Tabelle verzichten zu können), offenbar ein paar recht massive Inkonsistenzen - und Fehler - enthält: nicht immer wird der günstigste Plan verwendet und die Kosten der einzelnen Index-Zugriffe verändern sich deutlich, wenn sie im index join verwendet werden sollen (statt einzeln angesprochen zu werden). Plausibel sieht das Verhalten jedenfalls nicht aus.
Keine Kommentare:
Kommentar veröffentlichen