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

Статья, на которую вы ссылаетесь, датирована 2002 годом и очень старая. Просто используйте newsequentialid (доступно в SQL Server 2005 и выше). Это гарантирует, что каждый новый идентификатор, который вы создаете, больше предыдущего, что решает проблему фрагментации индекса / разделения страниц.

Однако еще один аспект, о котором я хотел бы упомянуть, который автор этой статьи умалчивает, заключается в том, что использование 16 байтов, когда вам нужно только 4, не является хорошей идеей. Предположим, у вас есть таблица с 500000 строк, в среднем 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 ГБ больше (см. Столбец «Всего», 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), это тоже сработает.