Ein Index, geclustert oder nicht geclustert, kann vom Abfrageoptimierer nur dann verwendet werden, wenn der Schlüssel ganz links im Index gefiltert wird. Wenn Sie also einen Index für Spalten (A, B, C) definieren, eine WHERE-Bedingung für [email protected] , auf [email protected] oder auf [email protected] AND [email protected] wird den Index nicht vollständig hebeln (siehe Hinweis). Dies gilt auch für Teilnahmebedingungen. Jeder WHERE-Filter, der A enthält berücksichtigt den Index:[email protected] oder [email protected] AND [email protected] oder [email protected] AND [email protected] oder [email protected] AND [email protected] AND [email protected] .
Also in Ihrem Beispiel, wenn Sie den gruppierten Index auf part_no erstellen als Schlüssel ganz links, dann eine Abfrage, die nach einer bestimmten part_id sucht wird nicht Verwenden Sie den Index, und für part-id muss ein separater nicht gruppierter Index vorhanden sein .
Nun zu der Frage, welcher der vielen Indexe geclustert werden soll ein. Wenn Sie mehrere Abfragemuster haben, die ungefähr die gleiche Wichtigkeit und Häufigkeit haben und sich in Bezug auf die benötigten Schlüssel widersprechen (z. B. häufige Abfragen von entweder part_no oder part_id ) dann berücksichtigen Sie andere Faktoren:
- Breite :Der Clustered-Index-Schlüssel wird von all als Suchschlüssel verwendet andere nicht gruppierte Indizes. Wenn Sie also einen breiten Schlüssel wählen (z. B. zwei Uniquidentifier-Spalten), machen Sie alle anderen Indizes breiter, verbrauchen somit mehr Platz, erzeugen mehr IO und verlangsamen alles. Wählen Sie also zwischen gleich guten Schlüsseln aus Lesesicht den schmalsten als gruppiert und machen Sie die breiteren nicht gruppiert.
- Konflikt :Wenn Sie bestimmte Einfüge- und Löschmuster haben, versuchen Sie, sie physisch zu trennen, damit sie in verschiedenen Teilen des Clustered-Index auftreten. Z.B. Wenn die Tabelle als Warteschlange mit allen Einfügungen an einem logischen Ende und allen Löschungen am anderen logischen Ende fungiert, versuchen Sie, den Clustered-Index so zu gestalten, dass die physische Reihenfolge dieser logischen Reihenfolge entspricht (z. B. Enqueue-Reihenfolge).
- Partitionierung Hinweis:Wenn die Tabelle sehr groß ist und Sie Partitionierung bereitstellen möchten, muss der Partitionierungsschlüssel der gruppierte Index sein. Ein typisches Beispiel sind historische Daten, die unter Verwendung eines Sliding-Window-Partitionierungsschemas archiviert werden. Auch wenn die Entitäten einen logischen Primärschlüssel wie 'entity_id' haben, wird der Cluster-Index durch eine datetime-Spalte erstellt, die auch für die Partitionierungsfunktion verwendet wird.
- Stabilität :Ein Schlüssel, der sich häufig ändert, ist ein schlechter Kandidat für einen gruppierten Schlüssel, da jeder den gruppierten Schlüsselwert aktualisiert und alle erzwingt nicht geclusterte Indizes, um den von ihnen gespeicherten Suchschlüssel zu aktualisieren. Da eine Aktualisierung eines gruppierten Schlüssels den Datensatz wahrscheinlich auch auf eine andere Seite verschieben wird, kann dies zu einer Fragmentierung des gruppierten Index führen.
Hinweis:nicht vollständig nutzen, da die Engine manchmal einen nicht geclusterten Index zum Scannen auswählt anstelle des gruppierten Index, einfach weil er schmaler ist und daher weniger Seiten zum Scannen hat. In meinem Beispiel haben Sie einen Index auf (A, B, C) und einen WHERE-Filter auf [email protected] und die Abfrageprojekte C , wird der Index wahrscheinlich verwendet, aber nicht als Suche, sondern als Scan, da er immer noch schneller ist als ein vollständiger Cluster-Scan (weniger Seiten).
