审核索引的使用情况不是一件容易的任务,但对于你服务器的性能来说是紧迫的
在审核SQLServer数据库里索引的使用情况的时候,有时我很受打击。例如,怎样去审核超过1500个表的数据库的索引?审核单个索引相对简单些,审核多个数据库里的成千上万个索引就不是一件容易的任务了。不管这项任务是否容易,对于优化SQLServer数据库的性能来说却是重要的。
在着手处理大量索引的审核时有两个不同的方法。一个是分成更小的更容易管理的单元,首先着眼于那些最可能影响SQLServer性能的索引。例如,你可以在你服务器最忙的数据库上启动审核,如果它有很多表,首先从最多数据的那些表开始,然后逐步到那些少一点的表。这样,你将在那些最可能有很大实际影响服务器性能的地方看到最初的成就。
另一个方法,也是我通常使用的方法(因为我有点懒),就是使用排除法。我的意思是如果看不到数据库的任何性能问题,就不必要评估数据库的每一个索引。但如果数据库显示正好存在性能问题,那么对那些不是最优的索引来说是一个好的调优机会,特别注意它们,尤其在数据库任务紧急的时候。如果有大量的索引要审核,那么先从最大的入手,因为它们最可能引起性能问题。例如,在有1500个表的数据库里,我仅仅小心的审核大约一打的表(都是很大的表),我认为它们应该受到最多的关注。
不管怎样,当你决定审核你所管理的数据库的索引的时候,你需要拿出合理的计划并系统地实现。
正如你已经看到的,我上面提供的审核列表不是很长。这是故意的。记住,这一系列关于性能监控的文章的目的是为了分辨容易和显而易见的性能问题,不是找出全部。上面列出来的将使你走很长的路去分辨和纠正容易的与索引相关的性能问题。一旦你掌握了它们,就可以更上一层楼了。例如,本网站上有很多索引相关的提示,大部分都很高级,比如下面的主题:
普通索引
聚集索引
复合索引
覆盖索引
非聚集索引
重建索引
索引调优向导
如果你还没有做过的话,你需要复习这些提示的网页。
你最近运行过索引调优向导吗?
微软在SQLServer7.0和2000里给我们最好的工具就是之一就是索引调优向导。它不是一个完美的工具,但它确实能帮助你分辨存在的索引是否正被使用,同时提供能加快查询的新索引。如果你正使用SQLServer2000,它也能推荐索引视图的使用。它使用目前你正在数据库里运行的查询,所以它的建议是基于你数据库是真正怎么使用的。它用来分析所需的查询来源于你用SQLServer事件探查器创建的跟踪。
当在一个新的SQLServer上进行性能审核时我做的第一件事就是在捕捉到的服务器活动的跟踪上运行索引调优向导。大多数情况下,它能帮助我快速的分辨出任何一个不被使用的可以被删掉的索引,分辨出为了提升数据库性能需要新建的索引。
这里有一些对于在使用索引调优向导审核SQLServer数据库索引时的提示:
当你在使用事件探查器捕捉数据时(索引调优向导用来分析性能),选择一天中数据库正常负荷的具有代表性的时段。我通常喜欢选择在上午或者下午3点,然后运行事件探查器跟踪至少一个小时以上。
一旦事件探查器跟踪完,索引调优向导可以随时运行。但是,一个好的想法是在数据库一段时间不忙的最适宜的时候运行,这是因为使用索引调优向导进行性能分析时会影响服务器的一些性能,既然不必要,对服务器性能产生负面影响就毫无意义。也要避免在产品服务器上运行分析(向导仍不得不连接到产品服务器),当执行分析的时候在另一台服务器上运行向导可以减少产品服务器的负载。
尽管要花费更多的时间去完成分析,你需要在索引调优向导的几个选项的设置期间列一个清单来帮助进行彻底的分析。这些包括:不要选择"Keep all existing indexes"(保留所有现有索引),因为你要分辨哪些索引没有用;指定你要进行"Tho