转换为顺序（组合）GUID - 如何处理现有数据？

Question

我们有一个包含500多个表的数据库，其中几乎所有表都有一个guid（uniqueidentifier）数据类型的聚集主键。

我们正在测试从通过.NET的Guid.NewGuid（）方法生成的“普通”“随机”guid切换到通过NHibernate guid.comb算法生成的顺序guid。这似乎运行良好，但是已经有数百万行具有“随机”主键值的客户会发生什么？

• 他们是否会从新生成的id现在是连续的这一事实中受益？
• 是否可以/应该对其现有数据进行任何处理？

感谢您提供任何有关此问题的指导。

- Eyvind

Answer 1

你可以这样做，但我不确定你是否想要这样做。我没有看到使用顺序guid的任何好处，事实上，除非涉及分布/复制原因，否则不建议使用guid作为主键。你使用了聚集索引吗？

话虽如此，如果你继续进行，我建议先从算法中加载一个带有值的表。

你将会遇到外键问题。你需要在上述表中关联旧的和新的guid，删除外键，执行事务性更新，然后重新应用外键。

我认为这不值得麻烦，除非你要完全放弃guid，转向基于整数的系统。

- James Westgate

---

将GUID作为主键有很多优点，绝对不是“不推荐”的做法。但将其用作聚集索引键确实不被推荐，因为它会导致糟糕的碎片化，并且会在每个相关的非聚集索引中使用大量空间。 - Nik

Answer 2

这取决于表是否集群在主键索引或其他索引上。例如，如果您正在创建具有GUID PK和创建日期的大量新记录的表，则通常最好按创建日期进行聚集以优化插入操作。

另一方面，根据所执行的查询，GUID的集群可能更好，此时使用连续的GUID可以帮助提高插入性能。我认为，没有深入了解用法，不可能对您的问题给出最终答案。

- Lucero

Answer 3

我遇到了类似的问题，我认为可以编写一个应用程序使用NHibernate guid.comb算法更新现有密钥来更新现有数据。为了将新密钥传播到相关的外键表，也许可以暂时级联更新？通过.NET代码执行此操作比使用SQL脚本要慢，另一个选择可能是在SQL中复制guid.comb逻辑，但不确定是否可行。

如果您选择保留现有数据，则使用guid.comb算法应该会有一些性能改进，当插入发生时仍然会出现页面分裂，但由于新的GUID是顺序而不是完全随机的，因此这至少会减少一些。另一个要考虑的选项是删除GUID主键上的聚集索引，尽管我不确定现有查询性能会受到多大影响。

- Simon