SQLServer数据库索引性能监控列表

分辨出覆盖索引在什么地方最有用是很困难的。虽然索引调优向导能有所帮助，但它仍会丢失大量的找到覆盖索引有用的地方的机会。另外，唯一的方法就是小心检查你数据库里运行的所有查询，当然这几乎是不可能的，除非你真的有时间且没有其他更好的事情去做。

在这点上，你监控的目的本身不是找出新的覆盖索引，而是理解它们以便你在你的环境里遇到它们有用的地方时能从中获得好处。?

索引重建的频率是多少？

随着时间的推移，索引会出现碎片，这会引起SQLServer访问它们时降低性能。唯一的解决方法就是定期整理数据库里所有索引的碎片。有几种不同的方法来整理，怎样去整理不会在这儿讨论，这个在SQLServer的帮助文档里有，本网站以后也会介绍。

你监控的目的是找出正在监控的数据库的索引是否在定期的整理碎片。整理碎片的频率从每天每周到每月不等，依赖于修改的频率和数据库的大小。如果数据库每天要进行很多修改，那么碎片整理应该更频繁的执行。如果数据库很大，这意味着碎片整理要花更长的时间，因此由于碎片整理过程占用太多的资源从而影响用户的使用，所以不能太频繁的整理碎片。作为监控的一部分，你要评估碎片产生的频率，找到最佳的频率。

至少，如果索引目前没有重建，而它们又需要重建，作为监控的一部分，你需要确认一些适当的索引重建计划。

索引的填充因子是多少？

和索引重建最相关的是填充因子。当创建一个新索引，或重建一个存在的索引时，你可以指定一个填充因子，它是在索引创建时索引里的数据页被填充的数量。填充因子设置为100意味着每个索引页100％填满，50％意味着每个索引页50％填满。

如果你创建一个填充因子为100的聚集索引（在一个非单调递增的列上），那意味着每当一个记录被插入（或修改）时，页拆分都会发生，因为在现存的页上没有这些数据的空间。很多的页拆分会降低SQLServer的性能。

举个例子：假定你刚刚用缺省的填充因子新创建了一个索引。当SQLServer创建它时，它把索引放在相邻的物理页面上，因为数据能够顺序的读所以这样会有最优的I/O访问。但当表随着INSERT、UPDATE、DELETE增加和改变时，发生了页拆分。当页拆分发生时，SQLServer必须在磁盘的某处分配一个新的页，这些新的页和最初的物理页不是连续的。因此，访问使用的是随机的I/O，而不是有顺序的I/O，这样访问索引页会变得更慢。

那么理想的填充因子是多少呢？它依赖于应用程序对SQLServer表的读和写的比率。首要的原则，按照下面的指导：

低更改的表（读写比率为100：1）：100％的填充因子

高更改的表（写超过读）：50-70％的填充因子

读写各一半的：80-90％的填充因子

在为应用程序找到最优的填充因子前也不得不进行试验。不要假定一个低的填充因子总比高的好。低的填充因子会减少页拆分，它也增加了SQLServer查询期间读的页数量，从而减少性能。太低的填充因子不仅增加I/O开销，也影响缓存。当数据页从磁盘移到缓存中时，整个页（包括空的空间）都移到缓存中。所以填充因子越低，不得不移到SQLServer缓存中的页面就越多，意味着同时为其他重要数据页驻留的空间就少，从而降低性能。

如果你没有指定填充因子，缺省的填充因子时0，意味着100％的填充因子（索引的叶页100％的填满，但索引的中间页有预留的空间）。

作为监控的一部分，你要决定新建索引或重建索引时的填充因子是多少。事实上，除了只读数据库，所有的情况，缺省值0都是不适合的。相反，你想要一个填充因子保留合适的自由空间，按照上面的讨论来做。