Jag håller med dig till 100 % - med en INT IDENTITY är mycket bättre!
GUIDs 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 kolumnen GUID 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:
1) 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.
2) klustringsnyckeln (kolumnen eller kolumnerna som definierar det "klustrade indexet" i tabellen) - detta ä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 vs. 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.
- GUID:er som PRIMÄRKEY och/eller klustrade nyckel
- Debatten om klustrade index fortsätter
- Ständigt ökande klustringsnyckel - The Clustered Index Debate...........igen!
- Diskutrymme är billigt - det är inte poängen!