SQL Server 中 COMB GUID 处的时间戳为 8 个字节或时间戳为 6 个字节

感谢精彩的文章，我们有 COMB GUID。根据目前的实施情况，有两种方法：

1. 使用最后 6 个字节作为时间戳：GUID作为多个数据库下的快速主键 http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database
2. 通过使用 Windows 刻度，使用最后 8 个字节作为时间戳：EF4.1 中的 GUID COMB 策略 (CodeFirst) https://stackoverflow.com/questions/6098972/guid-comb-strategy-in-ef4-1-codefirst/6100778#6100778

我们都知道，对于 GUID 处的 6 字节时间戳，需要有更多的随机字节来减少 GUID 的冲突。然而，将创建更多具有相同时间戳的 GUID，并且这些 GUID 根本不连续。因此，8 字节时间戳将是首选。

所以这似乎是一个艰难的选择。根据上面的文章GUID作为多个数据库下的快速主键 http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database， 它说：

在继续之前，请先了解一下此方法的简短脚注：使用 1 毫秒分辨率的时间戳意味着非常接近地生成的 GUID 可能具有相同的时间戳值，因此不会是连续的。对于某些应用程序来说，这可能是常见的情况，事实上，我尝试了一些替代方法，例如使用更高分辨率的计时器（例如 System.Diagnostics.Stopwatch），或者将时间戳与“计数器”结合起来以保证序列继续直到时间戳更新。然而，在测试过程中，我发现这根本没有明显的区别，即使在同一个一毫秒窗口内生成了数十甚至数百个 GUID。这也与 Jimmy Nilsson 在 COMB 测试中遇到的情况一致

只是想知道了解数据库内部的人是否可以分享一些关于上述观察的信息。是因为数据库服务器只是将数据存储在内存中，只有达到一定阈值才写入磁盘吗？因此，具有相同时间戳的非序列 GUID 的插入数据的重新排序通常会在内存中发生，因此性能损失最小。

Update:根据我们的测试，与随机 GUID 相比，COMB GUID 无法减少互联网上声称的表碎片。现在看来唯一的方法是使用 SQL Server 生成顺序 GUID。

你引用的文章是2002年的，很旧了。只需使用新闻序列ID http://technet.microsoft.com/en-us/library/ms189786.aspx（在 SQL Server 2005 及更高版本中可用）。这保证了您生成的每个新 id 都大于前一个，解决了索引碎片/页面拆分问题。

不过，我想提及的另一个方面是，当您只需要 4 个字节时，使用 16 个字节并不是一个好主意，该文章的作者对此进行了掩饰。假设您有一个表，其中包含 500,000 行，平均 150 字节（不包括聚集列），并且该表有 3 个非聚集索引（在每行中重复聚集列），每个索引依次包含平均 4 字节、25 字节和 50 字节的行不计算聚集列的字节数。

完美 100% 填充因子的存储要求如下（除 % 外，所有数字均以兆字节为单位）：

Item  Clust  50     25     4      Total
----  -----  -----  -----  -----  ------
GUID  79.1   31.5   19.6    9.5   139.7
 int  73.4   25.7   13.8    3.8   116.7
%imp   7.2%  18.4%  29.6%  60.0%   16.5%

在只有一个的非聚集索引中int4字节列（常见场景），将聚集索引切换为int使其缩小 60%！这直接意味着表上的任何扫描的性能提高了 60%——而且这是保守的，因为行越小，页面分割发生的频率就会越低，碎片也会保持得更久。

即使在聚集索引本身中，性能仍然提高了 7.2%，这并不是什么都不是的。

如果你用过怎么办GUID贯穿整个数据库，其中的表具有与此类似的配置文件，其中切换到int会导致大小减少 16.5%，而数据库本身的大小为 1.397 TB？您的整个数据库将增大 230 GB（请参阅“总计”列，139.7 - 116.7）。这可以转化为现实世界中用于高可用性存储的真金白银。它将您的磁盘采购计划提前，这对您公司的利润有害。

永远不要使用超过必要的数据类型。这就像无缘无故地给你的车增加重量：你will付出代价（如果不是速度，那就是燃油经济性）。

UPDATE

现在我知道您正在客户端代码中创建 GUID，我可以更清楚地看到问题的本质。如果你are能够将 GUID 的创建推迟到行插入时间，这是实现这一目标的一种方法。

首先，为您的系统设置默认值CustomerID column:

ALTER TABLE dbo.Customer ADD CONSTRAINT DF_Customer_CustomerID
   DEFAULT (newsequentialid()) FOR Customer;

现在您不必指定要插入的值CustomerID in any INSERT，您的查询可能如下所示：

DECLARE @Name varchar(100) = 'Acme Spy Devices';
INSERT dbo.Customer (Name)
OUTPUT inserted.CustomerID -- a GUID
VALUES (@Name);

在这个非常简单的示例中，您已将一个新行插入到Customer表，并向客户端返回一个包含刚刚创建的值的行集，所有这些都在一个查询中完成。

如果你想显式插入VALUES (newsequentialid(), @Name)那也行。