我对这个想法进行了一些确认，以修复性能不佳的数据库或更好的建议（如果有人有的话）。始终对更好的建议持开放态度。
我有一个非常大的数据库（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 …