GUID ydeevne

GUID s kan synes at være et naturligt valg for din primære nøgle - og hvis du virkelig skal, kan du sikkert argumentere for at bruge den til den PRIMÆRE NØGLE i tabellen. Hvad jeg kraftigt vil anbefale ikke at gøre er at bruge GUID kolonne som klyngenøgle , hvilket SQL Server gør som standard, medmindre du specifikt fortæller den ikke at gøre det.

Du skal virkelig holde to problemer adskilt:

den primære nøgle er en logisk konstruktion - en af kandidatnøglerne, der unikt og pålideligt identificerer hver række i din tabel. Dette kan være hvad som helst - en INT , en GUID , en streng - vælg det, der giver mest mening for dit scenarie.
klyngerøglen (den eller de kolonner, der definerer det klyngede indeks på bordet) - dette er en fysisk lagringsrelateret ting, og her er en lille, stabil, stadigt stigende datatype dit bedste valg - INT eller BIGINT som din standardindstilling.

Som standard bruges den primære nøgle på en SQL Server-tabel også som klyngenøgle - men sådan behøver det ikke at være! Jeg har personligt set massive præstationsgevinster, når den tidligere GUID-baserede primære/klyngede nøgle blev opdelt i to separate nøgler - den primære (logiske) nøgle på GUID'en og klynge- (bestillings-) nøglen på en separat INT IDENTITY(1,1) kolonne.

Som Kimberly Tripp - The Queen of Indexing - og andre har udtalt rigtig mange gange - en GUID som klyngingsnøgle er ikke optimal, da den på grund af dens tilfældighed vil føre til massiv side- og indeksfragmentering og til generelt dårlig ydeevne.

Ja, jeg ved det - der er newsequentialid() i SQL Server 2005 og nyere - men selv det er ikke helt sekventielt og lider derfor også af de samme problemer som GUID'en - bare lidt mindre fremtrædende.

Så er der et andet problem at overveje:klyngingsnøglen på et bord vil også blive tilføjet til hver eneste indgang på hvert ikke-klyngede indeks på din tabel - så du vil virkelig gerne sikre dig, at den er så lille som muligt. Typisk burde en INT med 2+ milliarder rækker være tilstrækkelig til langt de fleste tabeller – og sammenlignet med en GUID som clustering-nøgle kan du spare dig selv for hundredvis af megabyte lager på disk og i serverhukommelse.

Hurtig beregning - ved hjælp af INT vs. GUID som primær og klyngenøgle:

Basistabel med 1.000.000 rækker (3,8 MB vs. 15,26 MB)
6 ikke-klyngede indekser (22,89 MB vs. 91,55 MB)

TOTAL:25 MB vs. 106 MB - og det er bare på et enkelt bord!

Lidt mere stof til eftertanke - fremragende ting af Kimberly Tripp - læs det, læs det igen, fordøj det! Det er virkelig SQL Server-indekseringsevangeliet.