Ich möchte nur ein Wort der Warnung anbringen:Bitte sehr vorsichtig Wählen Sie Ihren gruppierten Index! Jede „normale“ Datentabelle sollte einen geclusterten Index haben, da ein geclusterter Index tatsächlich viele Operationen beschleunigt – ja, beschleunigen , sogar Einfügungen und Löschungen! Aber nur, wenn Sie sich für ein Gutes entscheiden gruppierter Index.
Es ist das am häufigsten replizierte Datenstruktur in Ihrer SQL Server-Datenbank. Der Gruppierungsschlüssel wird auch Teil jedes nicht geclusterten Indexes in Ihrer Tabelle sein.
Sie sollten bei der Auswahl eines Clustering-Schlüssels äußerste Sorgfalt walten lassen - er sollte sein:
-
schmal (4 Bytes ideal)
-
einzigartig (Es ist schließlich der "Zeilenzeiger". Wenn Sie ihn nicht eindeutig machen, erledigt SQL Server dies für Sie im Hintergrund, was Sie ein paar Bytes für jeden Eintrag kostet, multipliziert mit der Anzahl der Zeilen und der Anzahl der nicht gruppierten Indizes Sie haben - das kann sehr teuer werden!)
-
statisch (nie ändern - wenn möglich)
-
idealerweise immer steigend damit Sie nicht mit einer schrecklichen Indexfragmentierung enden (eine GUID ist das genaue Gegenteil eines guten Clustering-Schlüssels - aus diesem besonderen Grund)
-
es sollte nicht nullfähig sein und idealerweise auch eine feste Breite haben - ein
varchar(250)ergibt einen sehr schlechten Clustering-Schlüssel
Alles andere sollte hinter diesen Punkten eigentlich zweit- und drittrangig sein ....
Sehen Sie sich einige von Kimberly Tripps (The Queen of Indexing) an ) Blogbeiträge zum Thema - alles, was sie in ihrem Blog geschrieben hat, ist absolut unschätzbar - lies es, verdau es - lebe danach!
- GUIDs als PRIMARY KEYs und/oder der Clustering Key
- Die Clustered-Index-Debatte geht weiter...
- Ständig wachsender Clustering-Schlüssel - die Clustered-Index-Debatte..........schon wieder!
- Festplattenplatz ist billig - das ist nicht der Punkt!
