Ich kann Dir das ehrlich gesagt nicht erklären und ich hab da auch keine Ambitionen, mich in die Optimierungsalgorithmen beliebiger Optimizer reinzudenken.
Hmmm. Ich dachte, Du wüsstest das.
Zitat:
Schon bei vertauschter Reihenfolge der Felder in der Where Bedingung gegenüber der Indexdefinition wird der Index gar nicht genutzt oder nur teilweise bis zum vertauschten Feld.
Dann ist das kein Optimizer am Werk, denn der würde das ja optimieren, aber das ist mir bei einigen RDBMS auch schon aufgefallen. (Für Oracle gab es / gibt es wohl entsprechende
Query-Optimizer, die diese Reihenfolge dann optimieren). Na ja 'Optimizer' sind das schon, aber eigentlich sind es Strategieauswähler, weil bei jedem Schritt der
Query (eigentlich nur ein Baum aus Filtern, und Enumeratoren) die vermeindlich kostengünstigste Variante aus eine Pool an Möglichkeiten (Index-Seek, Index-Scan, Table-Scan, Sort, Bucket, Hash etc.) herausgepickt wird.
Übrigens wird ein Index-Scan benutzt, wenn einzelne Felder benötigt werden, die in Index-Informationen enthalten sind und wenn dafür dann kein Datensatz gelesen werden muss. Oder der Scan über den Index, um etwas zu finden, ist schneller als ein Table-Scan. Insofern sind einzelne Index eventuell geeignet, Scan-Vorgange zu beschleunigen, aber 'eigentlich'(*) auch nur dann, wenn sie kombiniert sind, oder weitere Felder huckepack mit ablegen ('INCLUDE' Klausel bei T-
SQL in Verbindung mit 'CREATE INDEX')
(*)'Eigentlich'=Ich weiss es nicht genau.
Aber was war das alles doch gleich? Ach ja, sekundär und wie Du schon sagtest per Experiment in ein paar Minuten belegt/widerlegt/erkannt.
Vom Diskussionsstoff her jedoch ein schönes Thema für einen anderen Thread.