COMB 导轨的性能价值

Question

Jimmy Nilsson 讨论了他的 COMB guid 概念here。这个概念在 NHibernate 和其他圈子中很流行，因为它的性能价值高于标准 GUID，而标准 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 行受影响）

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 vs Unique-Identifier for ID field in database 与 3rd 方链接。

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

Answer 2

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

请参阅my question，其中我使用来自 SQL Server 和 Oracle 的一些真实数据证实了这一点。

Answer 3

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