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

22

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.

sql-server sql-server-2005 clustered-index bernd_k
źródło

Odpowiedzi:

34

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.

gbn
źródło
23

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

mrdenny
źródło
Krótko, prosto, do rzeczy, więc otrzymuję moje +1. Pamiętaj, aby sprawdzić link do SQLSkills, ponieważ jest tam mnóstwo dobrych informacji.
AndrewSQL,
12
To brzmi jak polecenie. Nie wyjaśnienie lub logika jak do dlaczego powinniśmy ...
gbn
To nie tylko brzmi jak polecenie, ale także jest złe. Każda baza danych, która pobiera bardzo dużą liczbę wstawek / sekundę, spowoduje problemy z hotspotem, jeśli użyjesz klawiszy sekwencyjnych.
Thomas Kejser,
1
Powiedziałem preferowane, nie wymagane. W przypadku normalnych aplikacji, które stanowią 98% baz danych na świecie, klastrowany klucz w kolumnie tożsamości działa dobrze.
mrdenny,
4

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ść ...

lucky7_2000
źródło
1
+1 za podanie tego linku. Jest tam kilka interesujących wskazówek. Myślę jednak, że wynik byłby znacznie bardziej przekonujący, gdyby porównał dany scenariusz ze scenariuszem z indeksem nieklastrowanym cidx_trantime na tblTransactions (TranTime) lub inną alternatywą. Pamiętaj, że kiedy generujesz tak dużo danych, muszą istnieć wydajne sposoby ich odzyskiwania, nie możesz po prostu wrzucić wszystkiego do kupy.
bernd_k
@bernd_k: to kiepski przykładowy link. Tabela podrzędna ma zły, nieunikalny klucz klastrowany, który wymaga wewnętrznego unikatora
gbn
1
Wypróbuj ten eksperyment: kejser.org/boosting-insert-speed-by-generating-scalable-keys
Thomas Kejser