将Guid主键和聚集索引迁移到INT（Azure SQL）

Question

背景

我们最初开发了一个使用GUID作为PK并默认标记为Entity Framework的聚集索引的系统（我知道...）。我现在意识到这可能会影响数据库插入性能，特别是因为GUID被用作聚集索引。

我做了一些研究，找到了很多有用的信息，但我仍然不确定应该如何解决这个问题。此外，如果我们决定从GUID PK转换为INT，则有一个包含近一百万行的生产数据库需要迁移。

问题：

1. 另一种解决方案是将聚集索引更改为另一列（例如：DateTime），但如果我们的连接主要使用PK，那么这将带来多少性能差异？

2. 开始使用顺序guid（NHibernate Comb），但是如果我们现有的guid不是连续的，那么如果我们只是为新行开始使用顺序guid，它会产生影响吗？

3. 如果最佳解决方案是从GUID迁移到INT，那么是否可以使用Entity Code-First Migrations进行操作（如果可能的话）？

4. 我现在是否应该担心这个问题？也许这是预优化，但数据库正在快速增长，我不想在2-3百万行后才发现我们必须尽快解决它。

限制条件

• MSSQL（托管在Azure SQL上）
• Entity Framework Code-First Migrations（最好）
• 需要迁移的现有数据库

我感谢任何有建设性的反馈，可以帮助我做出正确的决定。我不需要一个详细的解决方案，只需要一些指导，指引我走向正确的道路。

- Ryan

---

嗨Ryan，你最后做了什么？我目前面临着同样的问题，考虑添加一个新列（int，identity），将其设置为聚集索引，并将我的PK（Guid）保持为非聚集索引。 - JCS

Answer 1

将GUID作为主键并不是问题，但在GUID列上有聚集索引时可能会导致性能问题。因此，您可以保留所有主键，并同时将聚集索引迁移到任何您想要的地方。

每个主键列（guid）上仍将存在一个索引，因此基于唯一值的联接性能将保持不变。更改只会影响写入和可能的读取性能。写入时会有较少的页面分裂，因为行将按顺序附加到索引末尾，而不是插入到随机页面中和排在聚集索引的中间和开头。

您可以使用NONCLUSTERED选项更改您的主键，并创建另一个聚集索引（它不必是PK甚至唯一的）。

- Ivan Starostin