将 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，那么是否可以通过实体代码优先迁移来实现（如果可能的话）？

4. 我现在还应该担心这个吗？也许是预优化，但数据库正在快速增长，我不想在 2 到 3 百万行之后继续前进并意识到我们必须尽快修复它。

约束

• MSSQL（托管在 Azure SQL 上）
• 实体框架代码优先迁移（最好）
• 需要迁移的现有数据库

感谢任何可以帮助我做出正确决定的建设性反馈。我不是在寻找书面的解决方案，而可能只是一些可以为我指明正确道路的指导。

Answer 1

将 GUID 用作 PK 不是问题。但是，当您在 GUID 列上有一个 CLUSTERED 索引时，它可能会导致性能问题。因此，您可以保持所有 PK 不变，同时将 CLUSTERED 索引迁移到任何您想要的位置。

每个 PK 列 (guid) 上仍然存在一个索引，因此唯一值的连接性能将是相同的。更改只会影响写入和可能读取的性能。写入时的页面拆分将更少，因为行将按顺序附加到索引的末尾，而不是插入到聚集索引中间和开头的随机页面中。

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