25k插入每日99％碎片集群GUID索引

Question

我有一个表具有主键作为集群GUID字段;我使用NEWSEQUENTIALID()而不是NEWID生成GUID。不幸的是，因为这个表每天看到〜25k-100k的插入，在几个小时内（默认：集群）主键索引变成99％碎片。

我最初使用NEWID而不是生成顺序ID，但即使重新创建表并重新插入使用NEWSEQUENTIALID（并指定作为主键列的默认值）的所有行，我仍然看到顺序中的碎片在几个小时内达到99％。 （该表目前有大约130万条记录

我曾想过用一个整数主键替换GUID，但我不确定这是否会起作用;另外，因为我们的团队使用主键的GUID而不是整数前进，我不认为我会有足够的买进来做到这一点。

什么是我的选项，以保持这个东西整理？我使用SQL Server Express，所以我没有有权访问SQL代理（因此不能定期运行维护计划来重建索引）

我也可能很可能在将来的某个时间点拆分此数据库/表（由于数据量），所以我可能需要合并表的GUID。

另外：我不能使用索引视图，因为我有一个内部选择，这将很难放松到一个连接。

Answer 1

以我个人的经验，抛出GUID s作为您的群集密钥可以h对你的系统有很大的正面影响 - 特别是在索引碎片方面！

我的新INT IDENTITY聚类指数几乎没有任何碎片 - 即使经过数月激烈的日常生产使用。绝对值得！

使用Guid数据类型作为SQL Server中的集群密钥是可怕的糟糕选择 - 无论您以何种方式查看它...

看到一些金佰利特里普的（女王索引）的博客文章的题目是

• GUIDs as primary keys and/or clustering keys
• Disk space is cheap - THAT's NOT THE POINT!

和别的她在博客上聚集键的话题...

Answer 2

看一看this simple query in the stackexchange data explorer。它看起来像newsequentialid()递增最重要的部分guid，而不是最小。这将成为你所看到的碎片化的一个可能原因。

如果您必须使用guid，可能需要考虑通过代码生成它们，并在插入语句中发送它们，而不是依赖于生成它们的数据库。使用“comb”技术，将当前时间戳用作guid的一部分，在最不重要的数字中递增。

---

编辑

..或者，如果你不想生成它们的代码，你可以在数据库

CAST(CAST(NEWSEQUENTIALID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER) 

为默认值的范围内做这样的事情，根据this modification to the above query

Answer 3

这是Guid索引的预期行为ge插入的数字。大多数情况下，您选择guid作为密钥只有，因为记录是由多个来源生成的，并且您需要使各个来源不会踩在彼此的脚趾上。这里的一个例子是离线的移动设备。当没有连接时，该领域的工作人员需要创建新记录，因此移动设备可以安全地使用guid作为密钥创建记录。当稍后重新联机时，设备可以安全地与数据库同步，而不用担心任何关键冲突。

如果您在单台服务器上生成GUID，通常最好使用简单的标识列。如果你真的想要guid，你仍然可以包含它们......你可能想要考虑一下使用它们作为你的聚集索引。您可能想要在guid上进行聚簇的唯一原因是，如果稍后您将回到表中并根据它的指导一次查询一条记录。你看到的插入率似乎不太可能。但是，如果是这种情况，可以通过减少索引上的填充因子来帮助缓解事情。这将增加使用的磁盘空间量（并且意味着稍后会有更多的磁盘查找），但页面填满的速度会更快，并且您将避免某些索引重新洗牌。