Question

Jimmy Nilsson讨论了他的COMB指导概念here。这个概念在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毫秒，经过时间= 15735   毫秒。

（585000行（s）受影响）

COMB GUID值的性能：

SQL Server执行时间：CPU   时间= 17500毫秒，经过时间= 16419   毫秒。

（585000行（s）受影响）

我错过了什么？ 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 vs Unique-Identifier for ID field in database与第三方链接。

如果ORM将GUID指定为PK而不是自然密钥或标准的基于int的代理密钥，则这是ORM的严重限制。还有一个客户端尾随摇摆数据库狗的情况。

Answer 2

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

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

此致马西莫

Answer 3

您生成新GUID的代码不正确。对于每一行，它创建一个非常不同的数字（您为每一行调用NEWID（））。您需要保持大部分GUID相同。

COMB guids的性能价值

3 个答案: