吉米·尼尔森(Jimmy Nilsson)在这里讨论他的COMB制导概念。这个概念在NHibernate中以及其他圈子中很流行,因为它比标准的GUID(通常随机性更高)的假定性能值高。
但是,在测试中似乎并非如此。我想念什么吗?
测试用例:
我有一个名为temp的表(不是临时表,只是一个名为“ temp”的表),其中有585,000行。我有一个名为“代码”的新表,希望将所有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执行时间:CPU时间= 17250毫秒,经过的时间= 15735毫秒。 (受影响的585000行)
SQL Server执行时间:CPU时间= 17250毫秒,经过的时间= 15735毫秒。
(受影响的585000行)
使用COMB GUID值的性能:
SQL Server执行时间:CPU时间= 17500毫秒,经过的时间= 16419毫秒。 (受影响的585000行)
SQL Server执行时间:CPU时间= 17500毫秒,经过的时间= 16419毫秒。
我想念什么?COMB GUID值导致了更长的时间,大概是因为额外的转换。我认为关键是通过使用最后6个字节的日期对GUIDS进行半排序来减少插入时间,但是性能提升似乎不存在。
其次,仅当在Guid列上有索引(PK,FK或其他类型的索引,已聚集或未聚集)时,您才会看到差异,因为标准guid与newguid或comb guid的成本是由于每次执行插入操作时,对索引数据重新排序。