解决方法
要查看索引碎片的两个最佳指标是:
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杂志上有关数据库维护的文章中阅读更多相关内容,参见基于2000的关于我在http://technet.microsoft.com/en-us/library/cc966523.aspx帮助编写的索引碎片整理最佳实践的白皮书,以及我在http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx碎片类别下的博客.
我觉得我有点过分回答了,但这是我的热门按钮之一.希望这可以帮助 :-)