Gleiche Abfrage verwendet verschiedene Indizes?

Question

Kann eine Select-Abfrage unterschiedliche Indizes verwenden, wenn der Wert einer Where-Bedingung geändert wird?

Die beiden folgenden Abfragen verwenden verschiedene Indizes und der einzige Unterschied ist der Wert des Zustand und typeenvoi = ‚EXPORT‘ oder und typeenvoi = ‚MAIL‘

select numenvoi,adrdest,nomdest,etat,nbessais,numappel,description,typeperiode,datedebut,datefin,codeetat,codecontrat,typeenvoi,dateentree,dateemission,typedoc,numdiffusion,nature,commentaire,criselcomp,crisite,criservice,chrono,codelangueetat,piecejointe, sujetmail, textemail 
      from v_envoiautomate 
      where etat=0 and typeenvoi='EXPORT' 
      and nbessais<1 


select numenvoi,adrdest,nomdest,etat,nbessais,numappel,description,typeperiode,datedebut,datefin,codeetat,codecontrat,typeenvoi,dateentree,dateemission,typedoc,numdiffusion,nature,commentaire,criselcomp,crisite,criservice,chrono,codelangueetat,piecejointe, sujetmail, textemail 
      from v_envoiautomate 
      where etat=0 and typeenvoi='MAIL' 
      and nbessais<1 

Kann mir jemand eine Erklärung geben?

Answer 1

Details zu Indizes werden als Statistiken in einem Histogramm-Dataset in SQL Server gespeichert.

Jeder Index in Bereiche chunked ist und jeder Bereich enthält eine Zusammenfassung der wichtigsten Werte innerhalb dieses Bereichs, Dinge wie:

• Bereich Höherwertiges
• Anzahl der Werte im Bereich
• Nummer verschiedenen Werte im Bereich (Mächtigkeit)
• Anzahl der Werte gleich den oberen Wert

... ein so weiter.

Sie können mit den Statistiken über einen gegebenen Index anzuzeigen:

DBCC SHOW_STATISTICS(<tablename>, <indexname>) 

Jeder Index hat ein paar Eigenschaften wie Dichte und schließlich Selektivität, sagen, dass die Abfrage-Optimierer, wie einzigartig jeder Wert in ein Index ist wahrscheinlich und wie effizient dieser Index ist, um Datensätze schnell zu finden.

Da Ihre Abfrage drei Spalten in der where-Klausel hat, ist es wahrscheinlich, dass jede dieser Spalten einen Index hat, der für den Optimierer nützlich sein könnte. Es ist auch wahrscheinlich, dass der Primärschlüsselindex berücksichtigt wird, falls die Selektivität anderer Indizes nicht hoch genug ist.

Letztendlich läuft es auf den Optimierer hinaus, der eine schnelle Beurteilung abruft, wie viele Seitenlesevorgänge erforderlich sind, um Ihre nicht geclusterten Indizes + Lesezeichen-Lookups mit Vergleichen mit den anderen Werten zu vergleichen, statt einen Tabellenscan durchzuführen .

Die Statistiken, auf denen diese Urteile basieren, können auch wild variieren; SQL Server tastet standardmäßig nur einen kleinen Prozentsatz der Zeilen einer signifikanten Tabelle ab, sodass die Selektivität dieses Indexes möglicherweise nicht repräsentativ für das Ganze ist. Dies ist besonders problematisch, wenn Sie im Index sehr unterschiedliche Schlüssel haben.

In diesem speziellen Fall, ich denke, Ihr typeenvoi Index ist in hohem Grade nicht einzigartig.Wenn dies so ist, zeigen die gesammelten Statistiken dem Optimierer wahrscheinlich an, dass einer der Werte seltener als der andere ist, und die Wahrscheinlichkeit, dass dieser Index ausgewählt wird, ist erhöht.

Answer 2

Wahrscheinlich hat es mit der "Kardinalität" zu tun, ich glaube das Wort ist, von den Werten in der Tabelle. Wenn es viel mehr Zeilen gibt, die mit dieser Klausel übereinstimmen, kann SQL Server entscheiden, dass eine Abfrage effizienter ist, wenn ein Index für eine andere Spalte verwendet wird. Dies ist ein Extremfall, aber wenn eine Zeile mit "MAIL" übereinstimmt, würde sie wahrscheinlich diesen Index verwenden. Wenn jede andere Zeile in der Tabelle 'EXPORT' war, aber nur die Hälfte dieser 'EXPORT' Zeilen eine etat von 0 hatte, würde sie wahrscheinlich den Index für diese Spalte verwenden.

Answer 3

Der Abfrageoptimierer in SQL Server (wie in den meisten modernen DBMS-Plattformen) verwendet eine Methode, die als "kostenbasierte Optimierung" bekannt ist. Dazu verwendet es Statistiken über die Tabellen in der Datenbank, um den benötigten E/A-Anteil zu schätzen. Der Optimierer berücksichtigt eine Reihe von semantisch äquivalenten Abfrageplänen, die er generiert, indem er einen grundlegenden Abfrageplan transformiert, der durch das Parsen der Anweisung generiert wurde.

Jeder Plan wird anhand einer Heuristik basierend auf den Statistiken zu den Tabellen auf Kosten bewertet. Die Statistik gibt es in verschiedenen Geschmacksrichtungen:

• Tabellen- und Indexreihe zählt

• Distributions Histogramme der Werte in den einzelnen Spalten.

Wenn die ocurrence von ‚MAIL‘ vs. ‚EXPORT‘ in den Verteilungs Histogrammen signifikant unterschiedlich ist der Abfrage-Optimierer kann mit unterschiedlichen optimalen Plänen kommen. Dies ist wahrscheinlich passiert.