Frederik bringt es schön auf den Punkt, und genau das predigt auch Kimberly Tripp:Der Clustering Key sollte stabil sein (niemals), immer größer werden (IDENTITY INT), klein und einzigartig.
In Ihrem Szenario würde ich den Clusterschlüssel lieber in die BIGINT-Spalte als in die VARCHAR(80)-Spalte setzen.
Zunächst einmal ist es mit der BIGINT-Spalte ziemlich einfach, die Eindeutigkeit zu erzwingen (wenn Sie die Eindeutigkeit nicht selbst erzwingen und garantieren, fügt SQL Server jeder einzelnen Ihrer Zeilen ein 4-Byte-„Uniquefier“ hinzu) und es ist VIEL kleiner im Durchschnitt als ein VARCHAR(80).
Warum ist Größe so wichtig? Der Clustering-Schlüssel wird auch zu JEDEM und jedem Ihrer nicht gruppierten Indizes hinzugefügt. Wenn Sie also viele Zeilen und viele nicht gruppierte Indizes haben, können 40-80 Byte gegenüber 8 Byte schnell einen RIESIGEN machen Unterschied.
Außerdem noch ein Performance-Tipp:Um die sogenannten Bookmark-Lookups (von einem Wert in Ihrem nicht gruppierten Index über den Clustering-Schlüssel in die eigentlichen Datenblattseiten) zu vermeiden, hat SQL Server 2005 den Begriff der "eingeschlossenen Spalten" eingeführt. in Ihren nicht gruppierten Indizes. Diese sind äußerst hilfreich und werden oft übersehen. Wenn Ihre Abfragen häufig die Indexfelder plus nur ein oder zwei andere Felder aus der Datenbank benötigen, ziehen Sie in Betracht, diese einzubeziehen, um das zu erreichen, was als "deckende Indizes" bezeichnet wird. Nochmals – siehe den ausgezeichneten Artikel von Kimberly Tripp – sie ist die SQL Server Indexing Goddess! :-) und sie kann das viel besser erklären als ich...
Um es zusammenzufassen:Setzen Sie Ihren Clustering-Schlüssel auf eine kleine, stabile, einzigartige Spalte - und Sie werden es gut machen!
Markus
