Frederik ładnie to podsumowuje i to właśnie głosi Kimberly Tripp:klucz grupowania powinien być stabilny (nigdy się nie zmienia), stale rosnący (IDENTITY INT), mały i niepowtarzalny.
W twoim scenariuszu wolę raczej umieścić klucz klastrowania w kolumnie BIGINT niż w kolumnie VARCHAR(80).
Po pierwsze, dzięki kolumnie BIGINT dość łatwo jest wymusić unikalność (jeśli sam nie wymuszasz i nie gwarantujesz unikalności, SQL Server doda 4-bajtowy „unikalny” do każdego z Twoich wierszy) i jest to DUŻO średnio mniejszy niż VARCHAR(80).
Dlaczego rozmiar jest tak ważny? Klucz klastrowania zostanie również dodany do KAŻDEGO i każdego z twoich nieklastrowanych indeksów - więc jeśli masz dużo wierszy i wiele nieklastrowanych indeksów, posiadanie 40-80 bajtów w porównaniu z 8 bajtami może szybko zrobić OGROMNY różnica.
Kolejna wskazówka dotycząca wydajności:aby uniknąć tak zwanych wyszukiwań zakładek (od wartości w indeksie nieklastrowanym przez klucz klastrowania do rzeczywistych stron liścia danych), w SQL Server 2005 wprowadzono pojęcie „włączonych kolumn”. w indeksach nieklastrowanych. Są one niezwykle pomocne i często pomijane. Jeśli Twoje zapytania często wymagają pól indeksowych oraz tylko jednego lub dwóch innych pól z bazy danych, rozważ uwzględnienie ich w celu uzyskania tzw. „indeksów pokrywających”. Ponownie — zobacz doskonały artykuł Kimberly Tripp — jest boginią indeksowania SQL Server! :-) i potrafi to wyjaśnić znacznie lepiej niż ja...
Podsumowując:umieść klucz klastrowania w małej, stabilnej, unikalnej kolumnie - a wszystko będzie dobrze!
Marek
