我们正在与供应商解决一个长期存在的问题。他们的软件有一种倾向，每周一到两次停止工作并停止工作，从而对我们的运营造成重大干扰。尽管我们向他们发送了许多 GB 的日志和数据库备份，但他们仍无法确定原因。最近，他们开始暗示问题出在我们的维护上，而不是出在他们的软件上（尽管没有长时间运行的查询、CPU/RAM/IO 压力，甚至在问题发生时出现死锁）。特别是他们说我们的索引是一个问题。
他们最喜欢使用的工具是 DBCC showcontig，尽管我认为 MS 不赞成使用该工具。他们尤其关注扫描密度和范围碎片。为了消除这个借口，我制定了一些积极的夜间维护，以<90% 的扫描密度或> 10% 的碎片重建索引。这在某种程度上使他们脱离了扫描密度序列，但他们仍然专注于范围碎片。即使在数小时前重建的索引上，DBCC showcontig 也会显示高度碎片化。下面是 dbcc_showcontig 和 sys.dm_db_index_physical_stats 的结果，他们指出一个表是“可能的问题”。
DBCC SHOWCONTIG
- 扫描的页面......................................: 1222108
- 扫描的范围............................................：152964
- 范围开关………………………………………………………………………………………………………………
- 平均 每个范围的页数………………………………………………………………………………………………………………………………………………
- 扫描密度 [最佳计数：实际计数]......：84.44% [152764:180905]
- 逻辑扫描分片 ..................... 3.24%
- 范围扫描碎片 ..................... 35.97%
- 平均 每页可用字节数........................: 692.5
- 平均 页面密度（完整）......................：91.44%
sys.dm_db_index_physical_stats
index_type_desc alloc_unit_type_desc Avg_fragmentation_in_percent page_count
CLUSTERED INDEX IN_ROW_DATA 3.236803129 1222070
NONCLUSTERED INDEX IN_ROW_DATA 0.680074642 48230
NONCLUSTERED INDEX IN_ROW_DATA 0.093237195 48264
NONCLUSTERED INDEX IN_ROW_DATA 0.03315856 48253
NONCLUSTERED INDEX IN_ROW_DATA 0.194653248 48291
NONCLUSTERED INDEX IN_ROW_DATA 0.393480436 58961
NONCLUSTERED INDEX IN_ROW_DATA 0.23622292 64346 …