我有一个非常大的数据库(2000万条记录每天增长约50万条),它们使用GUID作为PK.
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数据库的性能并防止未来的索引碎片地狱(在某种程度上)吗？或者我错过了一些非常重要的东西,它会跳起来咬我并引起更多的悲伤？
解决方法
更改为BIGINT的问题是添加到其他数据库和数据中的数据.将他们的数据库集成到中央商店.如果这不是一个考虑 – 并且永远不会考虑 – 那么,是的,BIGINT将很好地解决索引重新平衡问题.
在幕后,如果你没有指定聚集索引,sql Server会做同样的事情：它创建一个行ID字段&将所有其他索引映射到该索引.所以,通过自己动手,你就像sql解决它一样解决它.
