测量 SQLServer 数据库碎片/性能下降以及确定何时对 SQLServer 数据库表进行碎片整理的最佳实践是什么？
我最感兴趣的是了解有用的指标是什么，以及什么程度的性能下降会触发碎片整理。
答案1
我确信对此会有一些有趣的答案，因为对于要查看哪些指标存在很多分歧。我编写了 DBCC INDEXDEFRAG、SHOWCONTIG 并设计了 2005 年的替代品，还编写了在线图书内容，所以我将向您提供我的观点，并解释在线图书中的数字以及我选择的 2005 年维护计划向导。
索引碎片化的两个最佳指标是：1) (2005) 平均碎片化百分比 / (2000) 逻辑扫描碎片化 2) (2005) 平均页面密度 / (2000) 每页平均可用字节数
这些同样适用于聚集索引和非聚集索引。
1 衡量的是逻辑碎片的数量。当索引叶级页面的逻辑顺序与物理顺序不匹配时，就会出现这种情况。这会阻止存储引擎在范围扫描期间进行有效的预读。因此 #1 影响范围扫描性能，而不是单例查找性能。
2 衡量索引叶级每个页面上有多少浪费的空间。浪费的空间意味着您使用更多页面来存储记录，这意味着需要更多磁盘空间来存储索引、更多 IO 来读取索引以及更多内存来将页面保存在缓冲池中的内存中。
阈值？我的经验法则是碎片率低于 10%，则不做任何处理。碎片率 10%-30% 时，执行 ALTER INDEX ... REORGANIZE (2005) / DBCC INDEXDEFRAG (2000)。碎片率超过 30% 时，执行 ALTER INDEX ... REBUILD (2005) / DBCC DBREINDEX (2000)。这些是完整的概括，阈值你会有所不同。
要找到阈值，请根据碎片水平跟踪工作负载性能，并确定性能下降何时过多。此时，您需要解决碎片问题。在忍受碎片和消除碎片所造成的资源损失之间需要取得平衡。
我在这里还没有触及两种消除碎片的方法之间的权衡，比如使用 FILLFACTOR/PADINDEX 来尝试减轻碎片并减少碎片整理，更改模式/访问模式来缓解碎片，或者不同类型的维护计划。
哦，顺便说一句，我总是建议不要担心少于 1000 页的索引中的碎片问题。这是因为索引可能大部分驻留在内存中（并且因为人们要求一个数字，我必须想出一个）。
您可以在我撰写的有关数据库维护的 TechNet 杂志文章中阅读更多内容，网址为http://technet.microsoft.com/en-us/magazine/cc671165.aspx，在 2000 年我帮助撰写的索引碎片整理最佳实践白皮书中http://technet.microsoft.com/en-us/library/cc966523.aspx以及我的博客碎片化类别下的http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx。
我觉得我回答得有点过了，但这是我的热点问题之一。希望这能有所帮助 :-)