sql - 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 是您可以拥有的最有序的 key 类型。

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

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

所以我的观点是...您需要根据自己的情况做正确的事情。没有黄金方法可以做到这一点。以 Brent Ozar 的方式去做:

1. 弄清楚你想改变什么。
2. 在受控环境中测试您的更改
3. 确定变更是否产生了预期的影响。