如何判断何时需要对我的 SQLServer 数据库进行碎片整理？

Question

测量 SQLServer 数据库碎片/性能下降并确定何时对 SQLServer 数据库表进行碎片整理的最佳实践是什么？

我最感兴趣的是了解有用的指标是什么以及应该触发碎片整理的性能下降程度。

Answer 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 页的索引中的碎片。这是因为索引可能主要是内存驻留的（并且因为人们要求一个数字而我不得不想出一个）。

您可以在我在http://technet.microsoft.com/en-us/magazine/cc671165.aspx上的 TechNet 杂志关于数据库维护的文章中阅读更多相关信息，在我帮助撰写的关于索引碎片整理最佳实践的 2000 年白皮书中http://technet.microsoft.com/en-us/library/cc966523.aspx，以及我的博客上的 Fragmentation 类别，网址为http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx。

我认为我对此的回答有点过分，但这是我的热门按钮之一。希望这可以帮助 ：-）