GUID jsou problematické jako seskupené klíče kvůli vysoké náhodnosti. Tomuto problému se věnoval Paul Randal v posledním sloupku Q&A magazínu Technet:Chtěl bych použít GUID jako seskupený indexový klíč, ale ostatní argumentují, že to může vést k problémům s výkonem indexů. Je to pravda, a pokud ano, můžete vysvětlit proč?
Nyní mějte na paměti, že diskuse se týká konkrétně shluků indexy. Říkáte, že chcete sloupec použít jako „ID“, není jasné, zda to myslíte jako seskupený klíč nebo jen primární klíč. Obvykle se tyto dva překrývají, takže předpokládám, že jej chcete použít jako seskupený index. Důvody, proč je to špatná volba, jsou vysvětleny v odkazu na článek, který jsem zmínil výše.
U indexů bez klastrů mají GUID stále nějaké problémy, ale zdaleka ne tak velké, jako když jsou klíčem v klastru nejvíce vlevo v tabulce. Opět platí, že náhodnost GUID zavádí dělení a fragmentaci stránek, ať už pouze na úrovni indexu bez klastrů (mnohem menší problém).
Kolem používání GUID existuje mnoho městských legend, které je odsuzují na základě jejich velikosti (16 bajtů) ve srovnání s int (4 bajty) a slibují hroznou výkonnostní zkázu, pokud se použijí. To je trochu přehnané. Klíč o velikosti 16 může být na správně navrženém datovém modelu stále velmi výkonným klíčem. I když je pravda, že 4krát větší než int má za následek více nelistových stránek s nižší hustotou v indexech to u velké většiny tabulek není skutečným problémem. Struktura b-stromu je přirozeně dobře vyvážený strom a hloubka procházení stromu je zřídkakdy problém, takže hledání hodnoty založené na klíči GUID oproti klíči INT má podobný výkon. Procházení listovými stránkami (tj. skenování tabulky) nehledí na jiné než listové stránky a dopad velikosti GUID na velikost stránky je obvykle poměrně malý, protože samotný záznam je výrazně větší než zavedených 12 bajtů navíc. podle GUID. Takže bych bral rady z doslechu založené na „je 16 bajtů vs. 4“ s poměrně velkým zrnkem soli. Analyzujte jednotlivý případ od případu a rozhodněte, zda má dopad na velikost skutečný rozdíl:kolik jiných sloupce jsou v tabulce (tj. jaký vliv má velikost GUID na listové stránky) a kolik odkazů jej používá (tj. kolik jiných tabulky se zvětší, protože potřebují uložit větší cizí klíč).
Vyvolávám všechny tyto detaily jakousi provizorní obranu GUID, protože v poslední době se jim dostává hodně špatného tisku a některé jsou nezasloužené. Mají své přednosti a jsou nepostradatelné v jakémkoli distribuovaném systému (v okamžiku, kdy mluvíte o pohybu dat, ať už prostřednictvím replikace nebo synchronizačního rámce nebo čehokoli jiného). Viděl jsem špatná rozhodnutí, která byla učiněna na základě špatné pověsti GUID, když se jim vyhýbali bez řádného zvážení. Ale je pravda, že pokud musíte použít GUID jako seskupený klíč, ujistěte se, že řešíte problém s náhodností:použijte sekvenční guid pokud je to možné.
A nakonec, abych odpověděl na vaši otázku:pokud nemáte konkrétní důvod používat GUID, použijte INT.