梳状波导的性能值

Question

Jimmy讨论了他的梳形guid概念这里。这个概念在NHibernate和其他圈子中很流行，因为它比标准GUID具有更多的随机性。

然而，在测试中，情况似乎并非如此。我是不是遗漏了什么？

测试用例：

我有一个名为temp的表(不是临时表，只是一个名为“temp”的表)，其中有58.5万行。我有一个名为code的新表，希望将所有585,000段代码值从临时表复制到Codes表。我执行的测试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值的性能：

Server执行时间: CPU时间= 17250 ms，运行时间= 15735 ms。 (585000行受影响)

具有梳形GUID值的性能：

Server执行时间: CPU时间= 17500 ms，运行时间= 16419 ms。 (585000行受影响)

我遗漏了什么？梳形GUID值导致的时间稍长，大概是因为额外的转换。我认为关键是通过使用最后6个字节的日期半排序GUIDS来减少插入时间，但是性能增益似乎不存在。

Answer 1

第二，只有在Guid上有索引(PK、FK或其他类型的索引，集群或不聚集)时，才会看到差异，因为标准guid相对于newguid或梳guid的成本是由于每次执行insert时重新排序索引数据的高成本造成的。

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

Answer 2

我建议您没有看到订单的好处，因为目标表没有PK。所以，这是你看到的转换开销。如果它有PK，则在insert上仍必须对585 k行进行排序。SQL如何知道它是半排序的？

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

我想更进一步地说，这篇文章的日期是2002年，是针对SQL 2000的，并且已经被现实生活所超越。

在Server 2005中，我们使用顺序GUID来允许严格单调的GUID来解决一些问题。GUID作为PK已经在这里做了:最近的例子：INT数据库中ID字段的唯一标识符与第三方链接。

如果ORM将GUID指定为PK而不是自然键或基于int的标准代理键，则这是ORM的严重限制。还有一个客户端摇着数据库狗的案例。

Answer 3

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