我有一个非常大的数据库(2000万条记录每天增长约50万条),它们使用GUID作为PK.

我的疏忽,但PK集群在sql服务器上,并导致性能问题.

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

150个远程数据库中的每一个都不存储存储在中央sql数据库中的完整数据.它们只存储它们实际需要的数据的子集,并且所需的数据并不是唯一的(例如,150个数据库中的10个可能具有来自其他站点数据库的一些相同记录 – 它们共享).此外 – 数据实际上是在远程站点生成的 – 而不是在中心点 – 因此需要GUID.

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

幸运的是我们还没有活着 – 所以我可以根据需要进行更改并使其脱机,这至少是一些东西.

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

作为所有记录的守护者的中央DB的性能是可悲的 – 由于聚簇GUID作为许多记录的主键.索引碎片不在图表之列.

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

我将在GUID字段上创建一个Unique Non Clustered索引,这是主键.

较小的远程150数据库不需要知道中央sql Server数据库上的新PK – 它纯粹将用于组织数据库中的数据并停止糟糕的性能和碎片.

这会起作用并改善中央sql数据库的性能并防止未来的索引碎片地狱(在某种程度上)吗？或者我错过了一些非常重要的东西,它会跳起来咬我并引起更多的悲伤？