Czy „Unikaj tworzenia indeksu klastrowego opartego na kluczu przyrostowym” to mit z SQL Server 2000 dni?

Nasze bazy danych składają się z wielu tabel, z których większość używa klucza zastępczego liczby całkowitej jako klucza podstawowego. Około połowa tych kluczy podstawowych znajduje się w kolumnach tożsamości.

Tworzenie bazy danych rozpoczęło się za dni SQL Server 6.0.

Jedną z reguł przestrzeganych od samego początku było: Unikaj tworzenia indeksu klastrowego opartego na kluczu przyrostowym , jak można znaleźć w tych poradach dotyczących optymalizacji indeksu .

Teraz, używając SQL Server 2005 i SQL Server 2008, mam wrażenie, że okoliczności się zmieniły. Tymczasem te kolumny klucza podstawowego są idealnymi pierwszymi kandydatami na klastrowany indeks tabeli.

Mit sięga sprzed SQL Server 6.5, który dodał blokowanie na poziomie wiersza . I zasugerował tutaj Kalen Delaney .

Miało to związek z „gorącymi punktami” wykorzystania strony danych i faktem, że cała strona 2k (SQL Server 7 i wyższe strony 8k) była zablokowana, a nie wstawiony wiersz Edytuj, luty 2012

Znaleziono autorytatywny artykuł autorstwa Kimberly L. Tripp

„Debata o indeksie klastrowym trwa ...”

Hotspoty były czymś, co bardzo staraliśmy się uniknąć PRZED SQL Server 7.0 ze względu na blokowanie na poziomie strony (i w tym miejscu termin „hot spot” stał się terminem negatywnym). W rzeczywistości nie musi to być termin negatywny. Ponieważ jednak silnik pamięci masowej został ponownie zarchiwizowany / przeprojektowany (w SQL Server 7.0) i teraz obejmuje prawdziwe blokowanie na poziomie wierszy, motywacja (aby uniknąć hotspotów) już nie istnieje.

Edytuj, maj 2013 r

Link w odpowiedzi lucky7_2000 wydaje się wskazywać, że hotspoty mogą istnieć i powodują problemy. Jednak w artykule zastosowano nieunikalny indeks klastrowy w usłudze TranTime. Wymaga to dodania unikalizatora. Co oznacza, że ​​wskaźnik nie jest ściśle monotonicznie rosnący (i zbyt szeroki). Link w tej odpowiedzi nie jest sprzeczny z tą odpowiedzią ani z moimi linkami

Na poziomie osobistym pracowałem w bazach danych, w których wstawiałem dziesiątki tysięcy wierszy na sekundę do tabeli, która ma dużą kolumnę TOŻSAMOŚCI jako klastrowany PK.

Podsumowując, we współczesnych wersjach SQL Server kluczem do klastrów w kolumnie tożsamości jest obecnie preferowana opcja.

Kimberly Tripp ma fantastyczny wpis na blogu na ten temat. Mógłbym parafrazować, ale zaufaj mi, nie zrobiłbym tego sprawiedliwie. Przeczytaj. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increase-clustering-key-the-Clustered-Index-Debateagain!.aspx

Będąc tam, sprawdź niektóre z jej innych postów na temat kluczy klastrowania. Na jej stronie znajduje się bogactwo wiedzy.

sprawdź ten post:

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increase-clustered-index-keys-can-cause-latch-contention.aspx

tworzenie indeksu klastrowego na podstawie klucza inkrementującego może powodować powstawanie gorących punktów, które źle wpływają na wydajność ...