我们有一个包含500多个表的数据库，其中几乎所有表都有一个数据类型为guid（uniqueidentifier）的聚簇PK。
我们正在测试从通过.NET Guid.NewGuid（）方法生成的“正常”“随机”guid切换到通过NHibernate guid.comb algorithm生成的顺序guid的过程。这看起来效果很好，但是那些已经拥有数百万行“随机”主键值的客户呢？
提前感谢您对此的任何指示。
答案 0 :(得分：0)
你可以这样做，但我不确定你会这么做。我没有看到使用顺序guid有任何好处，实际上不建议使用guid作为主键，除非涉及分布/复制原因。您使用的是聚集索引吗？
如果你继续说，我建议先加载一个包含算法值的表格。
你将会遇到外键问题。您需要将旧的和新的guid关联到前面提到的表中，删除外键，执行事务更新，然后重新应用外键。
除非你完全离开guid说基于整数的系统，否则我认为值得麻烦。
答案 1 :(得分：0)
这取决于表是在主索引还是在另一个索引上聚类。例如，如果要在具有GUID PK和创建日期的表中创建大量新记录，则通常按创建日期进行聚类以优化插入操作。
另一方面，根据所做的查询，GUID上的集群可能更好，在这种情况下，使用顺序GUID可以帮助提高插入性能。我会说，如果没有深入了解使用情况，就不可能对你的问题给出最终答案。
答案 2 :(得分：0)
我遇到了类似的问题，我认为可以通过使用NHibernate guid.comb算法编写应用程序来更新现有密钥来更新现有数据。为了传播相关外键表的新密钥，可能会暂时级联更新吗？通过.NET代码执行此操作会比SQL脚本慢，另一个选项可能是在SQL中复制guid.comb逻辑但不确定是否可行。
如果您选择保留现有数据，使用guid.comb算法应该有一些性能改进，当插入发生时仍然会有页面拆分，但因为新的guid是顺序的而不是完全随机的，这至少会有所减少。另一个需要考虑的选择是删除GUID主键上的聚簇索引，但我不确定现有的查询性能会受到多大影响。