COMB guids的性能价值

Question

Jimmy Nilsson在这里讨论他的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执行时间:CPU时间= 17250 ms,已用时间= 15735 ms.

(受影响的585000行)

COMB GUID值的性能:

SQL Server执行时间:CPU时间= 17500毫秒,已用时间= 16419毫秒.

(受影响的585000行)

我错过了什么？COMB GUID值导致稍长的时间,可能是因为额外的转换.我认为重点是通过使用最后6个字节的日期对GUIDS进行半顺序来减少插入时间,但性能增益似乎不存在.

Answer 1

我建议你没有看到订单的好处,因为目标表没有PK.所以,这是你看到的转换开销.如果它有一个PK,585k行仍然必须在插入时排序.SQL如何知道它是半排序的？

现在,如果它是5,850 x 100行插入,那么您可能会看到一些好处,因为新行将"在末尾"而不是"在中间",因此减少了页面拆分和开销.

我会进一步说这篇文章的日期是2002年,适用于SQL 2000,并且已被现实生活所取代.

在SQL Server 2005中,我们有SEQUENTIAL GUID,允许严格单调的GUID来解决一些问题.作为PK的GUID也在这里完成:最近的例子:INT与第三方链接的数据库中ID字段的唯一标识符.

如果ORM将GUID指定为PK而不是自然密钥或标准的基于int的代理密钥,则这是ORM的严重限制.并且客户端尾部摇摆数据库狗的情况.

Answer 2

我认为只有在Guid colume上有索引(PK,FK或其他类型的索引,群集或非群集)才会看到差异,因为标准guid与newguid或comb guid的成本是由于每次执行插入时重新排序索引数据.

请参阅我的问题,其中我使用SQL Server和Oracle的一些实际数据证实了这一点:StackOverFlow问题

关心马西莫