cru*_*ble 5 page-splits fill-factor sql-server-2014
我们一直遇到一个表上的页面拆分问题,这是一个特别麻烦的问题 - 它是数据库中活动的审计日志,并且已经增长到 1TB 以上。主要索引位于记录类型上,它是 an NVARCHAR(100)
- 因为当有 5 种记录类型时您需要它 - 它比 aTINYINT
和记录 id更有意义- 它是 anNVARCHAR(200)
而不是记录的整数键。
它们还涵盖索引,包括键、旧值、新值等——非常广泛。
这是一个旧系统,不幸的是,这种审计的代码无处不在,而不是集中在一个程序中。它无法改变,我们正在经历漫长的微服务重写的痛苦过程。
因此,我将两个索引的填充因子从 100% 降低到 85%。
并且页面拆分变得更糟。我会说大约 3 倍的页面拆分。
这是一个普遍的结果吗?大多数建议说减少填充因子以提高页面拆分性能。我可以理解为什么它会这样做,因为键中数据的宽度。
建议是进一步降低填充因子,还是将其恢复原状?
当您有大量由随机 BTree 中间插入引起的页面拆分时,您的页面自然会平均达到 65%* 左右。拆分页面从 50% 满开始,任何填满超过 100% 的页面都会拆分回 50%。
因此,以 85% 的填充因子重建索引可能会暂时增加页面拆分,只是不如以 100% 的填充因子重建
*为什么不是 75%?我认为是因为每个拆分页覆盖了原始页面的一半值范围,新页面的填充速度是原始页面的一半。
更改填充因子实际上不可能导致更多页面拆分,假设您在 100% 填充因子重建/重组与 85% 填充因子重建/重组后立即测量页面拆分率。找到明确说明这一点的权威参考文献即使不是不可能,也是很困难的,但任何关于该主题的准确讨论都隐含地说明了这一点。如果您的系统上的页面拆分增加,这仅仅是由于已添加或修改的数据需要建立索引。
重要的是要注意(因为您没有提及),您将需要重建或重新组织聚集索引才能使填充因子真正执行任何操作。填充因子仅在创建、重建或重新组织索引时使用,它不会影响将多少数据放入新页面。
正如 David Browne 在他的回答中指出的那样,如果您的页面已拆分很多,则已经有很多页面具有大量可用空间。页面拆分后,将有两个页面约占 50% 的空间。当您使用填充因子重新组织/重建时,所有页面最终都已满 85%,因此您实际上可能减少了页面中的平均可用空间量。
请参阅指定索引的填充因子,Kendra Little 有一篇关于此主题的好文章,我也推荐在关于填充因子的 5 件事。
另外,我可能会补充一点,如果页面拆分并没有真正引起问题(用户痛苦等),那么它可能不值得“修复”。当您处理第三方应用程序或不再维护的事物时,通常值得考虑选择忽略一些低效操作,除非它们确实造成了问题。
归档时间: |
|
查看次数: |
139 次 |
最近记录: |