GUID prestanda

GUID s kan tyckas vara ett naturligt val för din primära nyckel - och om du verkligen måste, kan du förmodligen argumentera för att använda den för den PRIMÄRA KEY i tabellen. Vad jag starkt rekommenderar att inte gör använder GUID kolumnen som klustringsnyckel , vilket SQL Server gör som standard, om du inte specifikt säger åt den att inte göra det.

Du måste verkligen hålla isär två frågor:

den primära nyckeln är en logisk konstruktion - en av kandidatnycklarna som unikt och tillförlitligt identifierar varje rad i din tabell. Det här kan vara vad som helst - en INT , en GUID , en sträng - välj det som är mest meningsfullt för ditt scenario.
klustringsnyckeln (kolumnen eller kolumnerna som definierar det klustrade indexet på bordet) - det här är en fysisk lagringsrelaterad sak, och här är en liten, stabil, ständigt ökande datatyp ditt bästa val - INT eller BIGINT som ditt standardalternativ.

Som standard används primärnyckeln på en SQL Server-tabell också som klustringsnyckel - men det behöver inte vara så! Jag har personligen sett enorma prestandavinster när jag delar upp den tidigare GUID-baserade primära / klustrade nyckeln i två separata nyckel - den primära (logiska) nyckeln på GUID och klustringsnyckeln (beställningsnyckeln på en separat INT IDENTITY(1,1) kolumn.

Som Kimberly Tripp - The Queen of Indexing - och andra har sagt väldigt många gånger - en GUID som klustringsnyckel är inte optimal, eftersom den på grund av dess slumpmässighet kommer att leda till massiv sida- och indexfragmentering och till allmänt dålig prestanda.

Ja, jag vet - det finns newsequentialid() i SQL Server 2005 och uppåt - men även det är inte riktigt och helt sekventiellt och lider därför av samma problem som GUID - bara lite mindre framträdande så.

Sedan finns det en annan fråga att tänka på:klustringsnyckeln på ett bord kommer att läggas till varje post på varje icke-klustrade index på ditt bord också - så du vill verkligen se till att den är så liten som möjligt. Vanligtvis borde en INT med 2+ miljarder rader räcka för de allra flesta tabeller - och jämfört med en GUID som klustringsnyckel kan du spara hundratals megabyte lagring på disk och i serverminne.

Snabb beräkning - med INT kontra GUID som primär och klustringsnyckel:

Bastabell med 1 000 000 rader (3,8 MB mot 15,26 MB)
6 icke-klustrade index (22,89 MB mot 91,55 MB)

TOTALT:25 MB kontra 106 MB - och det är bara på ett enda bord!

Lite mer att tänka på - utmärkta grejer av Kimberly Tripp - läs det, läs det igen, smält det! Det är verkligen SQL Server-indexeringsevangeliet.