En 128-bitars GUID (uniqueidentifier )-nyckeln är naturligtvis 4x större än en 32-bitars int nyckel. Det finns dock några viktiga fördelar:
- Inga "IDENTITETSINFOGA"-problem vid sammanslagning av innehåll
- Om du använder ett COMB-värde istället för NEWSEQUENTIALID(), får du en "gratis" INSERT tidsstämpel. Du kan till och med
SELECTfrån primärnyckeln baserat på ett datum-/tidsintervall om du vill med några snyggaCAST()samtal. - De är globalt unika, vilket visar sig vara ganska praktiskt då och då.
- Eftersom det inte finns något behov av att spåra högvattenmärken kan ditt BL-lager tilldela värdet snarare än SQL Server, vilket eliminerar steget
SELECT scope_identity()för att hämta primärnyckeln efter en infogning. - Om det till och med är mycket möjligt att du kan ha mer än 2 miljarder poster, måste du använda
bigint(64 bitar) istället förint. När du har gjort det,uniqueidentifierär bara dubbelt så stor som enbigint. - Att använda GUID gör det säkrare att exponera nycklar i webbadresser etc. utan att utsätta dig för "gissa-ID"-attacker.
- Mellan hur SQL Server laddar sidor från disken och hur processorer nu är mestadels 64-bitars, bara för att ett tal är 128 bitar istället för 32 betyder det inte att det tar 4 gånger längre tid att jämföra. Det senaste testet jag såg visade att GUID:er är nästan lika snabba.
- Indexstorlek beror på hur många kolumner ingår. Även om själva GUID:erna är större, kan de extra 8 eller 12 byten vara obetydliga jämfört med de andra kolumnerna i indexet.
I slutändan är det kanske inte värt att klämma ut en liten prestandafördel genom att använda heltal att förlora fördelarna med en GUID. Testa det empiriskt och avgör själv.
Personligen använder jag fortfarande båda, beroende på situationen, men den avgörande faktorn har aldrig riktigt kommit till prestanda i mitt fall.