GUID са проблематични като клъстерирани ключове поради високата случайност. Този проблем беше разгледан от Пол Рандъл в последната колона с въпроси и отговори на Technet Magazine:Бих искал да използвам GUID като ключ за клъстериран индекс, но другите твърдят, че това може да доведе до проблеми с производителността с индексите. Вярно ли е това и ако е така, можете ли да обясните защо?
Сега имайте предвид, че дискусията е конкретно за клъстерите индекси. Казвате, че искате да използвате колоната като 'ID', но не е ясно дали го имате предвид като клъстериран ключ или просто първичен ключ. Обикновено двете се припокриват, така че предполагам, че искате да го използвате като клъстериран индекс. Причините, поради които това е лош избор, са обяснени в линка към статията, която споменах по-горе.
За неклъстерирани индекси GUID все още имат някои проблеми, но не толкова големи, колкото когато са най-левият клъстериран ключ на таблицата. Отново, произволността на GUID въвежда разделяне на страници и фрагментация, било то само на ниво неклъстериран индекс (много по-малък проблем).
Има много градски легенди около използването на GUID, които ги осъждат въз основа на техния размер (16 байта) в сравнение с int (4 байта) и обещават ужасна гибел на производителността, ако се използват. Това е леко преувеличено. Ключ с размер 16 може да бъде много ефективен ключ при правилно проектиран модел на данни. Въпреки че е вярно, че 4 пъти по-голямо от int води до повече по-ниска плътност на страници без листа в индексите това не е реална загриженост за огромното мнозинство от таблици. Структурата на b-дървото е естествено добре балансирано дърво и дълбочина на обиколката на дървото рядко е проблем, така че търсенето на стойност, базирана на GUID ключ, а не на INT ключ, е сходна по производителност. Обходът на листна страница (т.е. сканиране на таблица) не разглежда страниците без листа и влиянието на размера на GUID върху размера на страницата обикновено е доста малко, тъй като самият запис е значително по-голям от въведените допълнителни 12 байта от GUID. Така че бих възприел съвета да чуете, базиран на „е 16 байта срещу 4“ с доста голямо зърно сол. Анализирайте всеки отделен случай по случай и решете дали влиянието на размера прави реална разлика:колко други колоните са в таблицата (т.е. колко влияние оказва размера на GUID върху листовите страници) и колко препратки го използват (т.е. колко други таблиците ще се увеличат поради факта, че трябва да съхраняват по-голям външен ключ).
Извиквам всички тези подробности като нещо като импровизирана защита на GUID, защото напоследък получават много лоша преса и някои са незаслужени. Те имат своите предимства и са незаменими във всяка разпределена система (в момента, в който говорите за движение на данни, било то чрез репликация или синхронизираща рамка или каквото и да било). Виждал съм как се взимат лоши решения въз основа на лошата репутация на GUID, когато са били избягвани без надлежно обмисляне. Но е вярно, ако трябва да използвате GUID като клъстерен ключ, уверете се, че сте решили проблема с произволността:използвайте последователни ръководства когато е възможно.
И накрая, за да отговоря на въпроса ви:ако нямате конкретна причина да използвате GUID, използвайте INT.
