Jakie są najlepsze praktyki korzystania z GUID jako klucza podstawowego, w szczególności w odniesieniu do wydajności?

GUID może wydawać się naturalnym wyborem dla klucza podstawowego-a jeśli naprawdę musisz, prawdopodobnie możesz argumentować, że używasz go dla klucza podstawowego tabeli. To, co zdecydowanie zalecam , aby nie robić , to używanie kolumny GUID jako klucza klastrowego , co domyślnie robi SQL Server, chyba że wyraźnie mu tego nie nakazujesz.

Naprawdę trzeba trzymać dwa problemy z dala:

1. Klucz podstawowy jest konstrukcją logiczną - jednym z kandydatów klawisze, które jednoznacznie i niezawodnie identyfikują każdy wiersz w tabeli. To może być wszystko, naprawdę - INT, GUID, ciąg-wybierz to, co ma największy sens dla Twojego scenariusza.

2. Klucz klastrowy (kolumna lub kolumny, które definiują "indeks klastrowy" w tabeli)-jest to rzecz fizyczna związana z pamięcią masową, a tutaj mały, stabilny, stale rosnący typ danych jest najlepszym wyborem-INT lub BIGINT jako domyślna opcja.

By domyślnie klucz podstawowy w tabeli SQL Server jest również używany jako klucz klastrowania - ale nie musi tak być! Osobiście widziałem ogromny wzrost wydajności po rozbiciu poprzedniego klucza podstawowego / klastrowego opartego na GUID na dwa oddzielne klucze - klucz podstawowy (logiczny) na GUID i klucz klastrowania (zamawiania) na oddzielnej kolumnie INT IDENTITY(1,1).

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

Tak, Wiem - jest newsequentialid() W Sql Server 2005 i w górę - ale nawet to nie jest naprawdę i w pełni sekwencyjne, a zatem cierpi na te same problemy, co GUID - tylko trochę mniej widoczne.

Jest jeszcze jedna kwestia do rozważenia: klucz klastrowania na stole zostanie dodany do każdego wpisu na każdym niezaklustrowanym indeks na stole, jak również - więc naprawdę chcesz upewnić się, że jest tak mały, jak to możliwe. Zazwyczaj INT z 2+ miliardami wierszy powinien być wystarczający dla zdecydowanej większości tabel - a w porównaniu do GUID jako klucza klastrowania, możesz 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 klastrowego:

• tabela bazowa z 1 ' 000 ' 000 wierszy (3,8 MB vs. 15,26 MB)
• 6 indeksy niezakłócone (22.89 MB vs. 91.55 MB)

Razem: 25 MB vs. 106 MB - i to tylko na jednym stole!

Some more food for thought-excellent stuff by Kimberly Tripp-przeczytaj, przeczytaj jeszcze raz, przetraw! To indeksowanie serwera SQL.

• GUID jako klucz podstawowy i / lub klucz klastrowy
• dyskusja na temat indeksu klastrów trwa
• stale rosnący klucz klastrowy-Klaster Dyskusja O Indeksie..........jeszcze raz!
• miejsce na dysku jest tanie - o to właśnie chodzi!

PS: oczywiście, jeśli masz do czynienia z zaledwie kilkuset lub kilku tysięcy wierszy-większość z tych argumentów nie będzie miała większego wpływu na Ciebie. Jeśli jednak trafisz do dziesiątek, setek tysięcy wierszy, lub zaczniesz liczyć w milionach - wtedy te punkty stają się bardzo istotne i bardzo ważne dla Rozumiem.

Aktualizacja: jeśli chcesz mieć swoją kolumnę PKGUID jako klucz główny (ale nie klucz klastrowy), i inną kolumnę MYINT (INT IDENTITY) jako klucz do klastrowania-użyj tego:

CREATE TABLE dbo.MyTable
(PKGUID UNIQUEIDENTIFIER NOT NULL,
 MyINT INT IDENTITY(1,1) NOT NULL,
 .... add more columns as needed ...... )

ALTER TABLE dbo.MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED (PKGUID)

CREATE UNIQUE CLUSTERED INDEX CIX_MyTable ON dbo.MyTable(MyINT)

Zasadniczo: po prostu musisz jawnie powiedzieć PRIMARY KEY ograniczeniu, że jest to NONCLUSTERED (w przeciwnym razie jest tworzony jako twój klastrowy indeks, domyślnie) - a następnie tworzysz drugi indeks zdefiniowany jako CLUSTERED

To zadziała - i jest to prawidłowa opcja jeśli masz istniejący system, który wymaga "przeprojektowania" pod kątem wydajności. W przypadku nowego systemu, jeśli zaczniesz od zera, a nie jesteś w scenariuszu replikacji, zawsze wybrałbym ID INT IDENTITY(1,1) jako mój klastrowy klucz podstawowy-znacznie bardziej wydajny niż cokolwiek innego!