GUID'er er problematiske som klyngenøgler på grund af den høje tilfældighed. Dette problem blev behandlet af Paul Randal i den sidste Technet Magazine Q&A kolonne:Jeg vil gerne bruge en GUID som den klyngede indeksnøgle, men de andre argumenterer for, at det kan føre til ydeevneproblemer med indekser. Er dette sandt, og hvis ja, kan du forklare hvorfor?
Husk nu, at diskussionen specifikt handler om clustered indekser. Du siger, at du vil bruge kolonnen som 'ID', det er uklart, om du mener det som en klyngenøgle eller blot primærnøgle. Typisk overlapper de to hinanden, så jeg antager, at du vil bruge det som et klynget indeks. Årsagerne til, at det er et dårligt valg, er forklaret i linket til artiklen, jeg nævnte ovenfor.
For ikke-klyngede indekser har GUID'er stadig nogle problemer, men ikke nær så store, som når de er den klyngede nøgle længst til venstre i tabellen. Igen introducerer tilfældigheden af GUID'er sideopdelinger og fragmentering, det være sig kun på det ikke-klyngede indeksniveau (et meget mindre problem).
Der er mange urbane legender omkring brugen af GUID, der fordømmer dem baseret på deres størrelse (16 bytes) sammenlignet med en int (4 bytes) og lover forfærdelig ydeevne undergang, hvis de bliver brugt. Dette er lidt overdrevet. En nøgle i størrelse 16 kan være en meget velfungerende nøgle, på en korrekt designet datamodel. Selvom det er rigtigt, at det at være 4 gange så stor som en int resulterer i flere sider uden blade med lavere tæthed i indekser er dette ikke en reel bekymring for langt de fleste tabeller. B-træstrukturen er et naturligt velafbalanceret træ og dybden trægennemgang er sjældent et problem, så at søge efter en værdi baseret på GUID-nøgle i modsætning til en INT-nøgle er ens i ydeevne. En bladsidegennemgang (dvs. en tabelscanning) ser ikke på de ikke-bladede sider, og indvirkningen af GUID-størrelse på sidestørrelsen er typisk ret lille, da selve posten er væsentligt større end de ekstra 12 bytes, der indføres af GUID. Så jeg ville tage hør-sige-rådet baseret på 'er 16 bytes vs. 4' med et ret stort gran salt. Analyser individuelt fra sag til sag, og afgør, om størrelsespåvirkningen gør en reel forskel:hvor mange andre kolonner er i tabellen (dvs. hvor stor indflydelse GUID-størrelsen har på bladsiderne), og hvor mange referencer der bruger den (dvs. hvor mange andre tabeller vil stige på grund af det faktum, at de skal gemme en større fremmednøgle).
Jeg råber alle disse detaljer frem i en slags midlertidigt forsvar af GUID'er, fordi de har fået en masse dårlig presse på det seneste, og nogle er ufortjent. De har deres fordele og er uundværlige i ethvert distribueret system (i det øjeblik du taler om databevægelse, det være sig via replikering eller synkroniseringsramme eller hvad som helst). Jeg har set dårlige beslutninger blive truffet baseret på GUID's dårlige omdømme, når de blev undgået uden ordentlig overvejelse. Men det er sandt, hvis du skal bruge en GUID som klynget nøgle, skal du sørge for at løse problemet med tilfældigheder:brug sekventielle guider når det er muligt.
Og endelig for at besvare dit spørgsmål:hvis du ikke har en specifik grund til at bruge GUID'er, brug INT'er.