Wydajność GUID

GUID s może wydawać się naturalnym wyborem dla klucza podstawowego - a jeśli naprawdę musisz, prawdopodobnie możesz argumentować, aby użyć go jako klucza podstawowego tabeli. Czego zdecydowanie odradzam nie robić jest użycie GUID kolumna jako klucz klastrowania , co SQL Server robi domyślnie, chyba że wyraźnie zabronisz mu tego.

Naprawdę musisz oddzielić dwa problemy:

klucz podstawowy to konstrukcja logiczna — jeden z kluczy kandydujących, który jednoznacznie i niezawodnie identyfikuje każdy wiersz w tabeli. To może być naprawdę wszystko - INT , GUID , ciąg — wybierz, co jest najbardziej sensowne dla Twojego scenariusza.
klucz klastrowania (kolumna lub kolumny definiujące indeks klastrowy na stole) – to jest fizyczne rzecz związana z pamięcią masową, a tutaj najlepszym wyborem jest mały, stabilny, stale rosnący typ danych - INT lub BIGINT jako domyślną opcję.

Domyślnie klucz podstawowy w tabeli SQL Server jest również używany jako klucz klastrowy — ale nie musi tak być! Osobiście widziałem ogromny wzrost wydajności podczas dzielenia poprzedniego klucza podstawowego / klastrowego opartego na identyfikatorze GUID na dwa oddzielne klucze - klucz podstawowy (logiczny) w identyfikatorze GUID i klucz klastrowania (porządkujący) na oddzielnym INT IDENTITY(1,1) kolumna.

Jako Kimberly Tripp - Królowa indeksowania - i inni stwierdzili wiele razy - GUID jako klucz klastrowania nie jest optymalny, ponieważ ze względu na jego losowość prowadzi do ogromnej fragmentacji stron i indeksów oraz ogólnie do złej wydajności.

Tak, wiem - jest newsequentialid() w SQL Server 2005 i nowszych - ale nawet to nie jest naprawdę i w pełni sekwencyjne, a zatem również cierpi na te same problemy, co identyfikator GUID - tylko trochę mniej widoczne.

Jest jeszcze jedna kwestia do rozważenia:klucz klastrowania w tabeli zostanie dodany do każdego wpisu w każdym indeksie nieklastrowanym w Twojej tabeli - dlatego naprawdę chcesz się upewnić, że jest on tak mały, jak to możliwe. Zazwyczaj INT z ponad 2 miliardami wierszy powinien wystarczyć dla większości tabel – aw porównaniu z identyfikatorem GUID jako kluczem klastrowania można zaoszczędzić setki megabajtów pamięci na dysku i w pamięci serwera.

Szybkie obliczenia - przy użyciu INT a GUID jako klucz podstawowy i klucz klastrowy:

Tabela podstawowa z 1 000 000 wierszy (3,8 MB vs. 15,26 MB)
6 indeksów nieklastrowych (22,89 MB w porównaniu z 91,55 MB)

ŁĄCZNIE:25 MB vs. 106 MB - i to tylko na jednym stole!

Trochę więcej do myślenia - świetne rzeczy Kimberly Tripp - przeczytaj, przeczytaj jeszcze raz, przetrawij! To naprawdę ewangelia indeksowania SQL Server.