到 bigint 的顺序 GUID

Question

我目前正在监督一个到处都有（顺序）GUID 的数据库。该数据库的规模将在短期内显着增长。将整个 shebang 转换为使用 bigint 不会有太多工作。我在想，值得吗？

聚集索引会随着大小的增长而分崩离析，SQL 页面大小会增加，如果我继续使用顺序 GUID 的路径，我预计会遇到各种各样的麻烦。碎片化页面，可怕的索引..（尤其是在服务器重新启动的情况下，这会重置顺序 GUID 创建）

是否存在我可以出于某种原因保留 GUID 并使用 bigint 进行索引的世界？所有 SQL 语句都可以很容易地转换为对 SELECT 子句使用 bigint 列。

我最好的方法是什么？有什么理由保留 GUID 吗？还是我应该将所有内容都转换为 bigint 并从那里运行？

Answer 1

@simon_j_dm：顺序 GUID 不是按 BIGINT 排序的... Seq。 GUID 为您提供了 1000 个项目长的有序 GUID 序列...但在这些序列之间...您仍然会看到碎片。

BIGINT 是您可以拥有的最有序的密钥类型。

这是否意味着你应该改变？不一定，BIGINT 较小，因此您的内存压力较小，并且不会像 GUID 那样导致碎片。但是根据负载，您可能会看到使用 BIGINT 时会出现闩锁拥塞，而您不会在 GUID 上看到这种情况，因为它们本质上会将负载分散到更多页面上。

您可以通过降低填充因子来减少 GUID 的碎片。然而，这会导致数据库以 MB 大小膨胀，并且您不会立即填满数据页。而且您仍然需要在某些时候处理碎片。

所以我的意思是……你需要做适合你情况的事情。没有黄金方法可以做到这一点。按照布伦特奥扎的方式做：

1. 找出您想要更改的内容。
2. 在受控环境中测试您的更改
3. 确定更改是否产生了预期的影响。

Answer 2

如果您使用的是顺序 guid，那么它们的顺序与 bigint 一样。更改为 bigint 根本不会影响碎片。 然而，迁移到 bigint 会在这些列上减少 50% 的存储空间，这反过来也会减少内存使用和一般查询性能，因为内存授予可以更小并且 tempdb 使用会降低。 如果不是太痛苦，我会更改它，因为总是首选较小的数据类型。