测量SQLServer数据库碎片/性能下降并确定何时碎片整理SQLServer数据库表的最佳做法是什么？
我最感兴趣的是学习哪些有用的指标，以及哪种性能下降应该触发碎片整理。
我相信会有一些有趣的答案，因为在看什么指标方面存在很多分歧。 我写了DBCC INDEXDEFRAG，SHOWCONTIG并devise了他们2005年的替代品，再加上了在线书籍的内容，所以我会给你我的看法，并解释我select的Books Online和2005维护计划向导中的数字。
要查看索引碎片的两个最佳度量标准是：1）（2005）平均碎片百分比（2000）逻辑扫描碎片2）（2005）平均页面密度/（2000）每页平均字节数
这些同样适用于聚簇索引和非聚簇索引。
1正在测量有多less逻辑碎片。 这是索引叶级的页面逻辑顺序与物理顺序不匹配的原因。 这可以防止存储引擎在范围扫描期间执行高效的预读。 所以＃1影响范围扫描性能，而不是单身查找性能。
2正在测量索引叶级的每个页面上有多less浪费的空间。 浪费的空间意味着你正在使用更多的页面来存储logging，这意味着更多的磁盘空间来存储索引，更多的IO来读取索引，以及更多的内存来保存缓冲池内存中的页面。
阈值？ 我的一般经验法则是不到10％的碎片，什么都不做。 10-30％，做一个ALTER INDEX … REORGANIZE（2005）/ DBCC INDEXDEFRAG（2000）。 超过30％，做一个ALTER INDEX … REBUILD（2005）/ DBCC DBREINDEX（2000）。 这些是完整的概括， 你的门槛会有所不同。
要查找阈值，请根据碎片级别跟踪工作负载性能，并确定性能降级何时过多。 在这一点上，你需要在地址碎片。 在分散的生活和消除资源的冲击之间有一个平衡的行为。
在这里我没有涉及到两种删除碎片的方法，例如FILLFACTOR / PADINDEX来减less碎片，减less碎片整理，改变模式/访问模式以减less碎片，或者不同types的维护计划。
哦，顺便说一句，我总是build议不要打扰less于1000页索引的碎片。 这是因为索引可能主要是内存居民（因为人们要求一个号码，我必须拿出一个）。
有关数据库维护的TechNet杂志文章，请参阅http://technet.microsoft.com/zh-cn/magazine/cc671165.aspx ，该文档位于2000年的白皮书中，该白皮书介绍了我在帮助编写的索引碎片整理最佳实践http://technet.microsoft.com/en-us/library/cc966523.aspx ，并在我的博客下的碎片类别http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx 。
我认为这种回答太过分了，但这是我的热点之一。 希望这可以帮助 ：-）