Identyfikatory GUID są problematyczne jako klucze klastrowe ze względu na dużą losowość. Ten problem został rozwiązany przez Paula Randala w ostatniej kolumnie pytań i odpowiedzi w Technet Magazine:Chciałbym użyć identyfikatora GUID jako klucza indeksu klastrowego, ale inni twierdzą, że może to prowadzić do problemów z wydajnością indeksów. Czy to prawda, a jeśli tak, czy możesz wyjaśnić, dlaczego?
Pamiętaj teraz, że dyskusja dotyczy konkretnie klastrów indeksy. Mówisz, że chcesz użyć kolumny jako „ID”, nie jest jasne, czy masz na myśli klucz klastrowy, czy tylko klucz podstawowy. Zazwyczaj te dwa nakładają się, więc zakładam, że chcesz użyć ich jako indeksu klastrowego. Powody, dla których jest to zły wybór, wyjaśniono w linku do artykułu, o którym wspomniałem powyżej.
W przypadku indeksów nieklastrowanych identyfikatory GUID nadal mają pewne problemy, ale nie są tak duże, jak w przypadku kluczy klastrowych znajdujących się najbardziej po lewej stronie tabeli. Ponownie, losowość identyfikatorów GUID wprowadza podziały i fragmentację stron, czy to tylko na poziomie indeksu nieklastrowanego (o wiele mniejszy problem).
Istnieje wiele miejskich legend otaczających użycie GUID, które potępiają je na podstawie ich rozmiaru (16 bajtów) w porównaniu do int (4 bajty) i obiecują straszną utratę wydajności, jeśli zostaną użyte. To trochę przesadzone. Klucz o rozmiarze 16 może być nadal bardzo skutecznym kluczem, na odpowiednio zaprojektowanym modelu danych. Prawdą jest, że bycie 4 razy większym niż int skutkuje większą mniejszą gęstością stron bez kartek w indeksach nie stanowi to rzeczywistego problemu w przypadku zdecydowanej większości tabel. Struktura b-drzewa to naturalnie dobrze zrównoważone drzewo, a głębokość przemierzania drzewa rzadko jest problemem, więc szukanie wartości na podstawie klucza GUID, a nie klucza INT, ma podobną wydajność. Przechodzenie po stronie liścia (tj. skanowanie tabeli) nie obejmuje stron bez liści, a wpływ rozmiaru identyfikatora GUID na rozmiar strony jest zwykle dość mały, ponieważ sam rekord jest znacznie większy niż dodatkowe 12 bajtów wprowadzonych przez GUID. Więc posłuchałbym rady opartej na „to 16 bajtów vs. 4” z dość dużym ziarnem soli. Przeanalizuj każdy przypadek z osobna i zdecyduj, czy wpływ rozmiaru ma realną różnicę:ile innych kolumny są w tabeli (tj. jaki wpływ ma rozmiar GUID na stronach liści) i ile odwołań z niego korzysta (tj. ile innych tabele ulegną zwiększeniu, ponieważ muszą przechowywać większy klucz obcy).
Przytaczam wszystkie te szczegóły w rodzaju prowizorycznej obrony identyfikatorów GUID, ponieważ ostatnio otrzymują dużo złej prasy, a niektóre są niezasłużone. Mają swoje zalety i są niezbędne w każdym systemie rozproszonym (w momencie, gdy mówisz o przenoszeniu danych, czy to za pośrednictwem replikacji, frameworka synchronizacji, czy cokolwiek innego). Widziałem złe decyzje podejmowane w oparciu o złą reputację GUID, kiedy unikano ich bez należytego rozważenia. Ale to prawda, jeśli musisz użyć identyfikatora GUID jako klucza klastrowego, upewnij się, że rozwiązujesz problem losowości:użyj sekwencyjnych identyfikatorów kiedy to możliwe.
I na koniec, aby odpowiedzieć na Twoje pytanie:jeśli nie masz konkretnego powód do używania identyfikatorów GUID, użyj INT.
