GUID może wydawać się naturalnym wyborem dla twojego 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, które definiują „indeks klastrowy” w tabeli) – jest to fizyczny rzecz związana z pamięcią masową, a tutaj najlepszym wyborem jest mały, stabilny, stale rosnący typ danych -
INTlubBIGINTjako 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 GUID na dwa oddzielne klucze - klucz podstawowy (logiczny) w GUID , a klucz grupowania (porządkujący) na oddzielnym INT IDENTITY(1,1) kolumna.
Jako Kimberly Tripp
- królowa indeksowania - a inni twierdzili bardzo wiele razy - GUID ponieważ klucz klastrowania nie jest optymalny, ponieważ ze względu na jego losowość doprowadzi 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 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 powinno wystarczyć dla większości tabel - i w porównaniu z GUID jako klucz klastrowania możesz zaoszczędzić sobie setki megabajtów pamięci na dysku i w pamięci serwera.
Szybkie obliczenia - przy użyciu INT w porównaniu z GUID jako klucz podstawowy i 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.
- Identyfikatory GUID jako klucz podstawowy i/lub klucz klastrowy
- Debata na temat indeksu klastrowego trwa
- Ciągle rosnący klucz do klastrowania – ponownie debata na temat indeksów klastrowych!
- Miejsce na dysku jest tanie - to nie punkt!
Chyba że masz bardzo dobry powód , sugerowałbym użycie INT IDENTITY dla prawie każdej „prawdziwej” tabeli danych jako domyślnej dla ich klucza podstawowego — jest unikalna, stabilna (nigdy się nie zmienia), jest wąska, stale rośnie — wszystkie dobre właściwości który chcesz mieć w kluczu klastrowym, aby zapewnić szybką i niezawodną wydajność tabel SQL Server!
Jeśli masz jakąś „naturalną” wartość klucza, która również ma wszystkie te właściwości, możesz również użyć jej zamiast klucza zastępczego. Ale dwa ciągi o zmiennej długości max. Według mnie 20 znaków każdy nie spełnia tych wymagań.
