Answers:
我敢肯定会有一些有趣的答案，因为在看什么指标上存在很多分歧。我写了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/zh-cn/magazine/cc671165.aspx上有关数据库维护的《 TechNet杂志》文章中阅读有关此内容的更多信息，在我帮助撰写的基于2000的索引碎片整理最佳实践白皮书中http://technet.microsoft.com/zh-cn/library/cc966523.aspx，并且在我的博客上的“碎片”类别下为http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx。
我认为我对此回答过度，但这是我的热键之一。希望这可以帮助 ：-）