使用 GUID 作为主键修复数据库设计的最佳解决方案

Question

我对这个想法进行了一些确认，以修复性能不佳的数据库或更好的建议（如果有人有的话）。始终对更好的建议持开放态度。

我有一个非常大的数据库（20 多万条记录，每天增长约 1/2 百万），它使用 GUID 作为 PK。

我的疏忽，但 PK 聚集在 SQL 服务器上并导致性能问题。

guid 的原因 - 此数据库与 150 个其他数据库部分同步，因此 PK 需要是唯一的。同步不是由 SQL Server 管理的，而是构建了一个自定义过程，使数据保持同步以满足系统的要求——所有这些都基于该 GUID。

150 个远程数据库中的每一个都不存储中央 SQL 数据库中存储的完整数据。他们只存储他们实际需要的数据的一个子集，并且需要的数据对他们来说不是唯一的（150 个数据库中有 10 个可能有一些来自其他站点数据库的相同记录，例如 - 他们共享）。此外 - 数据实际上是在远程站点生成的 - 而不是在中心点 - 因此需要 GUID。

中央数据库不仅用于保持所有内容同步，而且将针对这个非常大的碎片数据库执行来自 3000 多个用户的查询。这在初始测试中已经是一个大问题。

幸运的是，我们还没有上线 - 所以我可以进行更改并在需要时将事情脱机，这至少是一些事情。

远程数据库的性能不是问题 - 数据子集非常小，数据库的总大小通常不会超过 1GB。记录会定期反馈到主系统，并在不再需要时从较小的 BD 中删除。

作为所有记录的管理员的中央数据库的性能是可悲的 - 由于聚集的 GUID 作为许多记录的主键。索引碎片不在图表之列。

所以 - 我解决性能问题的想法是创建一个新列 - Unsigned BIGINT IDENTITY(1,1) 然后更改表 BIGINT 列的 Clustered PK。

我会在作为主键的 GUID 字段上创建一个唯一的非聚集索引。

较小的远程 150 数据库不需要知道中央 SQL Server 数据库上的新 PK - 它纯粹用于组织数据库中的数据并阻止不良性能和碎片。

这是否会起作用并提高中央 SQL 数据库的性能并防止未来的索引碎片地狱（在一定程度上）？或者我错过了一些非常重要的东西，它会跳起来咬我并引起更多的悲伤？

Answer 1

您当然不需要在 GUID 上集群。如果您有一些东西可以让您唯一标识该 GUID以外的记录，我建议您考虑在该其他字段上构建唯一索引并使该索引聚集。如果没有，您可以自由地在其他字段上进行聚类，甚至使用非唯一索引。集群的方法最有利于拆分您的数据和查询 - 因此，如果您有一个“区域”字段或其他内容，这可能是您的集群方案的候选者。

更改为 a 的问题BIGINT是从其他数据库添加数据并将其数据库集成到中央存储中。如果这不是一个考虑因素——而且永远不会成为一个考虑因素——那么，是的，这BIGINT将很好地解决指数重新平衡问题。

在幕后，如果您不指定聚集索引，SQL Server 会做很多相同的事情：它创建一个行 ID 字段并将所有其他索引映射到该字段中。因此，通过自己动手，您正在解决它，就像 SQL 解决它一样。