Джимми Нильссон обсуждает свою концепцию руководства COMBВот, Эта концепция популярна в NHibernate, среди других кругов, из-за ее предполагаемого значения производительности по сравнению со стандартными GUID, которые обычно гораздо более случайны.

Тем не менее, при тестировании это не так. Я что-то пропустил?

Прецедент:

У меня есть таблица с именем temp (не временная таблица, просто таблица с именем "temp") с 585 000 строк в ней. У меня есть новая таблица с именем Codes, и я хочу скопировать все 585 000 значений кода из временной таблицы в таблицу кодов. Выполненный мною тест SQL был:

set statistics time on;

truncate table codes;
DBCC DBREINDEX ('codes', '', 90);

insert into codes (codeid, codevalue)
select newid(), codevalue from temp

truncate table codes;
DBCC DBREINDEX ('codes', '', 90);

insert into codes (codeid, codevalue)
select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp

Производительность со стандартными значениями GUID:

SQL Server Execution Times: CPU time = 17250 ms, elapsed time = 15735 ms.

(585000 row(s) affected)

Производительность со значениями COMB GUID:

SQL Server Execution Times: CPU time = 17500 ms, elapsed time = 16419 ms.

(585000 row(s) affected)

Что мне не хватает? значения COMID GUID приводили к немного большему времени, предположительно из-за дополнительных преобразований. Я думал, что смысл состоит в том, чтобы уменьшить время вставки путем полупорядкового упорядочения GUIDS с использованием даты для последних 6 байтов, но прирост производительности, похоже, отсутствует.