GUID är problematiska som klustrade nycklar på grund av den höga slumpmässigheten. Det här problemet togs upp av Paul Randal i den senaste fråge- och svarskolumnen i Technet Magazine:Jag skulle vilja använda en GUID som den klustrade indexnyckeln, men de andra hävdar att det kan leda till prestandaproblem med index. Stämmer detta och kan du i så fall förklara varför?
Tänk nu på att diskussionen specifikt handlar om klustrade index. Du säger att du vill använda kolumnen som 'ID', det är oklart om du menar det som klustrad nyckel eller bara primärnyckel. Vanligtvis överlappar de två varandra, så jag antar att du vill använda det som ett klustrat index. Anledningarna till att det är ett dåligt val förklaras i länken till artikeln jag nämnde ovan.
För icke-klustrade index har GUID fortfarande vissa problem, men inte alls lika stora som när de är den klustrade nyckeln längst till vänster i tabellen. Återigen, slumpmässigheten hos GUID introducerar siddelning och fragmentering, vare sig det bara är på den icke-klustrade indexnivån (ett mycket mindre problem).
Det finns många urbana legender kring GUID-användningen som fördömer dem baserat på deras storlek (16 byte) jämfört med en int (4 byte) och lovar hemsk prestandadom om de används. Detta är något överdrivet. En nyckel av storlek 16 kan vara en mycket funktionell nyckel, på en korrekt designad datamodell. Även om det är sant att vara fyra gånger så stor som en int resulterar i fler lägre densitet icke-bladssidor i index är detta inte ett verkligt problem för de allra flesta tabeller. B-trädstrukturen är ett naturligt välbalanserat träd och djupet trädpassering är sällan ett problem, så att söka efter ett värde baserat på GUID-nyckeln i motsats till en INT-nyckel är liknande i prestanda. En genomgång av bladsidor (dvs. en tabellskanning) tittar inte på sidor som inte är blad, och effekten av GUID-storlek på sidstorleken är vanligtvis ganska liten, eftersom själva posten är betydligt större än de extra 12 byte som introduceras av GUID. Så jag skulle ta hör-säg-rådet baserat på "är 16 byte mot 4" med en ganska stor nypa salt. Analysera individuellt från fall till fall och avgör om storlekseffekten gör en verklig skillnad:hur många andra kolumner finns i tabellen (dvs. hur stor påverkan har GUID-storleken på bladsidorna) och hur många referenser som använder den (dvs. hur många andra tabeller kommer att öka på grund av att de behöver lagra en större främmande nyckel).
Jag ropar ut alla dessa detaljer i ett slags provisoriskt försvar av GUID eftersom de har fått mycket dålig press på sistone och en del är oförtjänt. De har sina fördelar och är oumbärliga i alla distribuerade system (i det ögonblick du pratar om datarörelse, vare sig det är via replikering eller synkroniseringsramverk eller vad som helst). Jag har sett dåliga beslut fattas baserat på GUID:s dåliga rykte när de undveks utan ordentlig hänsyn. Men det är sant, om du måste använda en GUID som klustrad nyckel, se till att du åtgärdar slumpmässighetsproblemet:använd sekventiella guider när det är möjligt.
Och slutligen, för att svara på din fråga:om du inte har en specifik anledning att använda GUID, använd INT.