8 байта за клеймо за време или 6 байта за клеймо за време в COMB GUID в SQLServer

Статията, която споменахте, е от 2002 г. и е много стара. Просто използвайте newsequentialid (налично в SQL Server 2005 и по-нова версия). Това гарантира, че всеки нов идентификатор, който генерирате, е по-голям от предишния, решавайки проблема с фрагментирането на индекса/разделянето на страници.

Друг аспект, който обаче бих искал да спомена, който авторът на тази статия премълча, е, че използването на 16 байта, когато имате нужда само от 4, не е добра идея. Да приемем, че имате таблица с 500 000 реда, средно 150 байта, без клъстерираната колона, и таблицата има 3 неклъстерирани индекса (които повтарят клъстерната колона във всеки ред), всеки на свой ред с редове, средно 4 байта, 25 байта и 50 байтове, без да се брои клъстерираната колона.

Тогава изискванията за съхранение при перфектен коефициент на запълване от 100% са (всички числа в мегабайти, с изключение на %):

Item  Clust  50     25     4      Total
----  -----  -----  -----  -----  ------
GUID  79.1   31.5   19.6    9.5   139.7
 int  73.4   25.7   13.8    3.8   116.7
%imp   7.2%  18.4%  29.6%  60.0%   16.5%

В неклъстърирания индекс, който има само една int колона от 4 байта (често срещан сценарий), превключването на клъстерирания индекс към int го прави с 60% по-малък! Това се превръща директно в 60% подобрение на производителността за всяко сканиране на таблицата – и това е консервативно, защото с по-малки редове разделянето на страници ще се случва по-рядко и фрагментацията ще остане по-добра за по-дълго време.

Дори в самия клъстериран индекс все още има 7,2% подобрение на производителността, което изобщо не е нищо.

Какво ще стане, ако използвате GUIDs в цялата си база данни, която има таблици с подобен профил като този, където преминаването към int би довело до 16,5% намаление на размера, а самата база данни е с размер 1,397 терабайта? Цялата ви база данни ще бъде с 230 Gb по-голяма (вижте колоната Общо, 139,7 - 116,7). Това се превръща в реални пари в реалния свят за съхранение с висока наличност. Той премества графика ви за закупуване на дискове по-рано във времето, което е вредно за крайния резултат на вашата компания.

Никога не използвайте по-големи типове данни от необходимото. Това е като да добавите тегло към колата си без причина: вие ще платите за това (ако не заради скоростта, то заради разхода на гориво).

АКТУАЛИЗАЦИЯ

Сега, след като знам, че създавате GUID във вашия клиентски код, мога да видя по-ясно естеството на вашия проблем. Ако можете да отложите създаването на GUID до времето за вмъкване на ред, ето един начин да го постигнете.

Първо задайте стойност по подразбиране за вашата колона CustomerID:

ALTER TABLE dbo.Customer ADD CONSTRAINT DF_Customer_CustomerID
   DEFAULT (newsequentialid()) FOR Customer;

Сега не е нужно да указвате каква стойност да вмъкнете за CustomerID във всеки INSERT и вашата заявка може да изглежда така:

DECLARE @Name varchar(100) = 'Acme Spy Devices';
INSERT dbo.Customer (Name)
OUTPUT inserted.CustomerID -- a GUID
VALUES (@Name);

В този много прост пример сте вмъкнали нов ред в таблицата Customer и сте върнали набор от редове на клиента, съдържащ току-що създадената стойност, всичко това в една заявка.

Ако искате изрично да вмъкнете VALUES (newsequentialid(), @Name), това също ще работи.