6

我们有一个包含 500 多个表的数据库，其中几乎所有表都有一个数据类型为 guid（唯一标识符）的集群 PK。

我们正在测试从通过 .NETs Guid.NewGuid() 方法生成的“正常”“随机”guid 到通过NHibernate guid.comb 算法生成的顺序 guid 的切换。这似乎运作良好，但是对于已经拥有数百万行具有“随机”主键值的客户端呢？

  • 他们会受益于从现在开始生成的新 ID 将是连续的这一事实吗？
  • 可以/应该对他们现有的数据做些什么吗？

提前感谢您对此的任何指示。

4

3 回答 3

0

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

话虽如此，如果你继续，我建议先加载一个包含算法值的表。

您将在使用外键时遇到麻烦。您需要关联上述表中的新旧 guid，删除外键，执​​行事务更新，然后重新应用外键。

我认为这不值得麻烦，除非您完全放弃 guid 来使用基于整数的系统。

于 2010-04-13T11:02:21.397 回答
0

这取决于表是聚集在主索引上还是另一个索引上。例如，如果您在具有 GUID PK 和创建日期的表中创建大量新记录，则通常按创建日期进行聚类以优化插入操作是有意义的。

另一方面，根据完成的查询，GUID 上的集群可能会更好，在这种情况下，使用顺序 GUID 可以帮助提高插入性能。我想说，如果没有深入了解用法，就不可能对您的问题给出最终答案。

于 2010-04-13T11:35:45.303 回答
0

I'm facing a similar issue, I think it would be possible to update existing data by writing an application to update your existing keys using the NHibernate guid.comb algorithm. To propogate the new keys to related foreign key tables maybe it would be possible to temporarily cascade updates? Doing this through .NET code would be slower than an SQL script, another option might be to duplicate the guid.comb logic in SQL but not sure if this is possible.

If you choose to retain the existing data, using the guid.comb algorithm should have some performance improvement, there will still be page splitting when inserts occur but because new guids are sequential instead of totally random this will be at least somewhat reduced. Another option to consider would be to remove the clustered index on your GUID primary key, although I'm not sure how much existing query performance will be impacted.

于 2010-09-14T04:51:47.953 回答