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大小膨胀，并且您不会立即填满数据页。而且你仍然需要在某些时候处理碎片。

所以我的观点是......你需要做适合自己情况的事情。没有什么好办法可以做到这一点。这是Brent Ozar的方式：

1. 找出你想要改变的东西。
2. 在受控环境中测试您的更改
3. 如果变更产生了想要的影响，那就很容易。

Answer 2

如果你使用顺序guid，那么它们就像bigint一样被命令。更改为bigint根本不会影响碎片。 然而，移动到bigint会使这些列的存储空间减少50％，这反过来也会减少内存使用和一般查询性能，因为内存授权可以更小并且tempdb使用率降低。 如果不是太痛苦，我会改变它，因为小数据类型总是首选。