Wenn Sie eine Tabelle mit einem gruppierten Index für den Primärschlüssel (int) haben, ist es redundant und schlecht, einen (oder mehrere) nicht gruppierte Indizes zu haben, die diese Primärschlüsselspalte als eine der Spalten im Nicht-Cluster enthalten -clustered Index?
Tatsächlich könnte es berechtigte Gründe geben, einen nicht-gruppierten Index identisch mit dem gruppierten Index zu erstellen. Der Grund dafür ist, dass geclusterte Indizes das Gepäck der Zeilendaten tragen, was eine sehr geringe Reihendichte zur Folge haben kann. Ie. Aufgrund breiter Felder, die sich nicht im Clustered-Schlüssel befinden, können Sie 2-3 Zeilen pro Seite haben, aber der Clustered-Index-Schlüssel beträgt nur etwa 20 Byte. Wenn ein nicht gruppierter Index für genau dieselben Schlüssel und dieselbe Reihenfolge wie der gruppierte Index aufweist, würde dies eine Dichte von 2-3 Hunderten Schlüsseln pro Seite ergeben. Viele Aggregatabfragen, die für OLAP / BI-Workloads typisch sind, können durch den nicht gruppierten Index effizienter beantwortet werden, da die E / A-Vorgänge hunderte Male reduziert werden.
Wie bei nicht gruppierten Indizes, die Teile des gruppierten Schlüssels oder sogar die gleichen Schlüssel enthalten, aber in anderer Reihenfolge, sind alle Wetten deaktiviert, da sie offensichtlich für eine Vielzahl von Abfragen verwendet werden können.
Die Antwort auf Ihre Frage lautet also: Es hängt davon ab .
Für eine genauere Antwort müssen Sie das genaue Schema Ihrer Tabelle (n) und die genauen beteiligten Abfragen teilen.
Ja, dies ist normalerweise nicht erforderlich, da die Spalten des gruppierten Indexes bereits jedem Indexeintrag im nicht gruppierten Index hinzugefügt wurden.
Warum? Der Wert des gruppierten Schlüssels ermöglicht es SQL Server, eine Datenzeile zu "finden" - es ist der "Zeiger" auf die eigentlichen Daten - offensichtlich muss sie im nicht gruppierten Index gespeichert werden. Wenn Sie "Smith, John" nachgeschlagen haben und Sie mehr über diese Person wissen müssen, müssen Sie zu den tatsächlichen Daten gehen - & gt; Dies geschieht, indem der Wert des Clustering-Schlüssels in den Indexknoten des nicht gruppierten Indexes eingefügt wird.
Dieser clustered Schlüsselwert ist bereits vorhanden und daher ist es in der Regel redundant und unnötig, diesen Wert explizit dem nicht gruppierten Index hinzuzufügen. Es ist schlecht, weil es einfach Platz verschwendet, ohne Ihnen einen Vorteil zu geben.
Ich bin mit Remus dabei - ein gruppierter Index ist nicht wirklich ein Index - er sagt Ihnen, wie die Daten in Seiten organisiert sind. (In Ihrem Fall ist es auch der Primärschlüssel, aber das muss nicht dasselbe sein). Nicht gruppierte Indizes enthalten diese Informationen zum Zeilen-Locator, also ja, sie sind redundant.
Aber Wenn ein nicht gruppierter Index für gilt und das Datenzeilen-Lesezeichen nicht verwendet werden muss, kann es verwendet werden eine Menge effizienter als der gruppierte Index und die Effizienz steigt, wenn das Verhältnis der Größe der Datenzeile zur Größe des nicht gruppierten Indexes zunimmt.
Ich habe festgestellt, dass, wenn Sie die Zugriffspfade in Ihrem Abfrage-Workload gut beherrschen, manchmal ein paar selektive, nicht geclusterte Indizes verwendet werden können, um Clusterauswahlmöglichkeiten vollständig zu eliminieren - Heap-Tabelle, PK und einige gute nicht gruppierte Indizes, und Sie sind fertig.
Es gibt keine 100% Antwort, aber die Antwort ist fast definitiv.
Die anderen Indizes helfen bei Joins und Sortierungen (allgemein). Vorausgesetzt, dass der Primärschlüssel bereits indiziert ist, kann der Optimierer, wenn er darauf zugreifen kann, diesen verwenden.
Wenn ein weiterer Index aus einer Join / Sort-Perspektive benötigt wird, welche zusätzliche Hilfe bietet die PK im Index-Mix? Wenn es vorher nicht basierend auf dem PK beitreten konnte, wird es jetzt nicht gehen. Und es wird auch niemandem beim Sortieren helfen.
Tags und Links sql-server indexing clustered-index