Zgadzam się z Tobą w 100% - używając INT IDENTITY jest znacznie lepszy!
Identyfikatory GUID mogą 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ć używa kolumny GUID jako klucza klastrowania , co SQL Server robi domyślnie, chyba że wyraźnie zabronisz mu tego.
Naprawdę musisz oddzielić dwa problemy:
1) klucz podstawowy to konstrukcja logiczna — jeden z kluczy kandydujących, który jednoznacznie i niezawodnie identyfikuje każdy wiersz w tabeli. Może to być wszystko, naprawdę - INT, GUID, łańcuch - wybierz to, co jest najbardziej sensowne dla twojego scenariusza.
2) 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 - INT lub BIGINT jako opcja domyślna.
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 (uporządkowania) na oddzielnym identyfikatorze INT (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 — użycie INT vs. GUID jako klucza podstawowego i klucza klastrowego:
- 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 - doskonałe 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!
