sql - COMB 指南的性能值

Question

Jimmy Nilsson 讨论他的 COMB guid 概念 here 。这个概念在 NHibernate 和其他圈子中很流行，因为它比标准 GUID 的性能值(value)通常要随机得多。

但是，在测试中，情况似乎并非如此。我错过了什么吗？

测试用例:

我有一个名为 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 Execution Times: CPU time = 17250 ms, elapsed time = 15735 ms.

(585000 row(s) affected)

COMB GUID 值的性能:

SQL Server Execution Times: CPU time = 17500 ms, elapsed time = 16419 ms.

(585000 row(s) affected)

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

Answer 1

我建议您看不到订单优势，因为目标表没有 PK。所以，这就是您看到的转换开销。如果它有 PK，则 585k 行仍必须在插入时排序。 SQL 如何知道它是半排序的？

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

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

在 SQL Server 2005 中，我们有顺序 GUID，允许严格单调的 GUID 来解决某些问题。 GUID 作为 PK 也已在此处完成:最近的示例:INT vs Unique-Identifier for ID field in database带有第 3 方链接。

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