Es ist schwer, dies prägnanter zu formulieren als Brad McGehee, MVP von SQL Server:
Als Faustregel sollte jede Tabelle einen gruppierten Index haben. Im Allgemeinen, aber nicht immer, sollte sich der gruppierte Index in einer Spalte befinden, die monoton ansteigt – wie z. B. eine Identitätsspalte oder eine andere Spalte, in der der Wert ansteigt – und eindeutig ist. In vielen Fällen ist der Primärschlüssel die ideale Spalte für einen Clustered-Index.
BOL gibt dieses Gefühl wieder:
Mit wenigen Ausnahmen sollte jede Tabelle einen geclusterten Index haben.
Dafür gibt es viele Gründe, die hauptsächlich darauf beruhen, dass ein Clustered-Index Ihre Daten physisch im Speicher anordnet .
-
Wenn sich Ihr gruppierter Index in einer einzelnen Spalte monoton erhöht, erfolgen die Einfügungen auf Ihrem Speichergerät der Reihe nach und Seitenteilungen finden nicht statt.
-
Clustered-Indizes sind effizient, um eine bestimmte Zeile zu finden, wenn der indizierte Wert eindeutig ist, wie z. B. das allgemeine Muster der Auswahl einer Zeile basierend auf dem Primärschlüssel.
-
Ein gruppierter Index ermöglicht häufig effiziente Abfragen von Spalten, die häufig nach Wertebereichen durchsucht werden (
between,>usw.). -
Clustering kann Abfragen beschleunigen, bei denen Daten üblicherweise nach einer oder mehreren bestimmten Spalten sortiert werden.
-
Ein Clustered-Index kann bei Bedarf neu erstellt oder neu organisiert werden, um die Tabellenfragmentierung zu kontrollieren.
-
Diese Vorteile können sogar auf Aufrufe angewendet werden.
Möglicherweise möchten Sie keinen gruppierten Index haben für:
-
Spalten mit häufigen Datenänderungen, da SQL Server die Daten im Speicher dann physisch neu anordnen muss.
-
Spalten, die bereits von anderen Indizes abgedeckt werden.
-
Breite Schlüssel, da der Clustered-Index auch in Non-Clustered-Index-Lookups verwendet wird.
-
GUID-Spalten, die größer sind als Identitäten und auch zufällige Werte (werden wahrscheinlich nicht sortiert), obwohl
newsequentialid()könnte verwendet werden, um die physische Neuordnung während des Einfügens zu verringern. -
Ein seltener Grund für die Verwendung eines Heaps (Tabelle ohne Clustered-Index) ist, wenn auf die Daten immer über Nonclustered-Indizes zugegriffen wird und die RID (interne Zeilenkennung von SQL Server) bekanntermaßen kleiner als ein Clustered-Index-Schlüssel ist.
Aufgrund dieser und anderer Überlegungen, z. B. Ihrer speziellen Anwendungs-Workloads, sollten Sie Ihre Clustered-Indizes sorgfältig auswählen, um den größtmöglichen Nutzen für Ihre Abfragen zu erzielen.
Beachten Sie auch, dass wenn Sie einen Primärschlüssel für eine Tabelle in SQL Server erstellen, standardmäßig ein eindeutiger gruppierter Index erstellt wird (falls noch nicht vorhanden). Das bedeutet, dass, wenn Sie eine Tabelle finden, die keinen Clustered-Index, aber einen Primärschlüssel hat (wie alle Tabellen sollten), ein Entwickler zuvor die Entscheidung getroffen hat, sie auf diese Weise zu erstellen. Möglicherweise möchten Sie einen zwingenden Grund haben, dies zu ändern (von denen es viele gibt, wie wir gesehen haben). Das Hinzufügen, Ändern oder Löschen des Clustered-Index erfordert das Neuschreiben der gesamten Tabelle und alle nicht geclusterten Indizes, daher kann dies bei einer großen Tabelle einige Zeit dauern.
