SQL Server索引自动优化工具

  前段接手了个优化项目,大概要求是对公司现有的1W多张表进行索引优化,完善现有的,剔除无效的索引。鉴于人手严重不足(当时算两个半人的资源),打消了逐个库手动去改的念头。当前的程序结构不允许搞革命的做法,只能搞搞改良,所以准备搞个自动化工具去处理。原型刚开发完,开会的时候以拿出来就遭到运维DBA团队强烈抵制,具体原因不详。最后无限延期。这里把思路分享下。欢迎拍砖。

  整个思路是这样的,索引都是为查询和更新服务的,但是不合适的索引又会对插入和更新带来负面影响。面对表上现有的索引想识别那些是有效的不太可能。那么根据现有的数据使用情况重建所有的新索引不就解决了嘛。根据查询生成全新索引,然后和现有对比,不吻合的全部删除,原来没有的创建。虽然说对于正在运行的系统来说风险还是蛮大的。但是可以做临界测试嘛。

  具体解决方案如下:

  首先在热备的数据库服务器上定期抓取缓存的执行计划(原本想抓取SQL发现有些SQL实在掺不忍睹,没有自动化解析的可能性),然后连同该执行的执行次数即表的统计信息一起down到一个备用服务器的数据表中。

  执行计划积累几次后,开始解析。由于执行计划是格式良好的XML文件,加上微软提供执行计划的XSD文件。我们可以反向推出各节点对应的SQL谓词(这个XSD到现在都没找到官方的说明,只能反向推出关联)。例如建立索引我们比较关心三类谓词,分别为:Select,Join,Where. 只要拿到这些我们就能建立良好的索引。原理很简单,Join和Where都是索引键的依据,而Select可以斟请添加到Index的Include中。

  解析的时候也不是针对单个执行计划,而是将所有执行计划全分解后进行统计处理。好处就是能够知道那些表字段被引用的最多,那些是外键列。那些数据被反复查询。例如可以得出TableA的Col1列在一天的业务过程中被Join了10W次,被Where2W次。而Col2则被Select了10W次,仅仅被Where了100次。这样我们建立索引的基础就是基于表的而不是基于单个查询的。最终生成的Index将权衡查询频率和查询的重要性,如果某个业务查询特别重要,但执行频率不高我们可以提供权重,优先建立索引。当然创建Index还要参考表的数据分布以决定Index中字段的顺序。

  好了,准备工作完成,开始建索引。当前拥有的条件,表数据分布,表字段分别被查询引用次数(Select,Join,Where),以及这些SQL谓词出现的次数。根据这些如何创建索引开始的想法是逐个分析,考虑所有可能性然后创建。发现这种方式只适合人脑,让电脑做得先让电脑的智商增长到120以上才有可行性。发现逆向思维这里同样大有用处,既然不能一下子创建最合适的,那我们就根据执行计划得出的组合创建所有的Index组合。凡是Join和Where都放到Index的Key里。例如:

  select t1.A, t1.B, t1.C, t2.J, t2.k from Table1 t1 Join Table1 t2 on t1.A = t2.j Where t1.A = 'param'

  草创的索引就是:

  Index(A,B)includ(C) 和 Index(j)include(j,k)

  关于Select如果是小数据类型且Alter的执行计划中该数据修改频率很小的都放到Include里去进去。大数据类型和修改比较频繁的就算了。这样我们剔除相互覆盖的。部分重叠的,部分重叠到底保留那一个参考执行频率和查询重要性。差异很小的就合并并为一个,如:

  1、Index (A,B,C)Include(D)

  2、Index(A,B,D)Include(C)

  直接合并为:

  Index(A,B)Include(C,D)

  当然如果Alert的特别少也可以合并成Index(A,B,C,D)这个要参考C,D字段的修改频率。和主键重叠的剔除。这样留下的基本上就是我们需要的索引了。

  对比现有索引进行甄别覆盖的过程就略过。简单的拉出来Create Index 进行解析处理就好了。发布的时候很简单。写个脚本在业务比较少的时候做Drop和Create就完成了。项目源代码因为设计到公司的保密问题就不上传了。一个注意的地方对于简单查询的SQL执行计划缓存的时候会比较短且一旦缓存不够就会被清理掉。要注意这些SQL的执行频率的误差。

  SqlserverR2 XSD:schemas.microsoft./sqlserver/2004/07/showplan/sql2008/showplanxml.xsd

  总结的节点映射列举如下:

  查询sql执行计划都包含在节点"StmtSimple"中,如果没有这个节点一般就是其它类型的SQL的执行计划。

  Join关联的节点和自身类型有关一般包含在Hash,Marger中,如何Join同时又是Where条件的话则会出现在SeekKey和Compare节点中,因为Join的列都是成对出现,这里很容易识别,有一个是参数(@开头)或常量(type="Const")则必定是Where条件。

  Select最终输出字段比较容易找到,第一个OutputList节点就是。

  需要注意的是有因为一般列每个ColumnReference都包含库名,表名,列信息,但是系统表则不会。注意剔除。

时间: 2024-09-17 16:48:09

SQL Server索引自动优化工具的相关文章

SqlServer 索引自动优化工具_MsSql

鉴于人手严重不足(当时算两个半人的资源),打消了逐个库手动去改的念头.当前的程序结构不允许搞革命的做法,只能搞搞改良,所以准备搞个自动化工具去处理.原型刚开发完,开会的时候以拿出来就遭到运维DBA团队强烈抵制,具体原因不详.最后无限延期.这里把思路分享下.欢迎拍砖. 整个思路是这样的,索引都是为查询和更新服务的,但是不合适的索引又会对插入和更新带来负面影响.面对表上现有的索引想识别那些是有效的不太可能.那么根据现有的数据使用情况重建所有的新索引不就解决了嘛.根据查询生成全新索引,然后和现有对比,

优化SQL Server索引的小技巧

server|技巧|索引|优化  SQL Server中有几个可以让你检测.调整和优化SQL Server性能的工具.在本文中,我将说明如何用SQL Server的工具来优化数据库索引的使用,本文还涉及到有关索引的一般性知识.关于索引的常识  影响到数据库性能的最大因素就是索引.由于该问题的复杂性,我只可能简单的谈谈这个问题,不过关于这方面的问题,目前有好几本不错的书籍可供你参阅.我在这里只讨论两种SQL Server索引,即clustered索引和nonclustered索引.当考察建立什么类

优化SQL Server索引

SQL Server中有几个可以让你检测.调整和优化SQL Server性能的工具.在本文中,将说明如何用SQL Server的工具来优化数据库索引的使用,本文还涉及到有关索引的一般性知识.关于索引的常识 影响到数据库性能的最大因素就是索引.由于该问题的复杂性,我只可能简单的谈谈这个问题,不过关于这方面的问题,目前有好几本不错的书籍可供你参阅.我在这里只讨论两种SQL Server索引,即clustered索引和nonclustered索引.当考察建立什么类型的索引时,你应当考虑数据类型和保存这

优化 SQL Server 索引的小技巧_MsSql

在本文中,我将说明如何用SQL Server的工具来优化数据库索引的使用,本文还涉及到有关索引的一般性知识. 关于索引的常识 影响到数据库性能的最大因素就是索引.由于该问题的复杂性,我只可能简单的谈谈这个问题,不过关于这方面的问题,目前有好几本不错的书籍可供你参阅.我在这里只讨论两种SQL Server索引,即clustered索引和nonclustered索引.当考察建立什么类型的索引时,你应当考虑数据类型和保存这些数据的column.同样,你也必须考虑数据库可能用到的查询类型以及使用的最为频

Sql Server 查询性能优化之走出索引的误区分析_MsSql

据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是,或者干脆把整个查询SQL直接发给DBA,让DBA直接帮忙优化了,所以造成的状况就是开发人员对于索引的理解.认识很局限,以下就把我个人对于索引的理解及浅薄认识和大家分享下,希望能解除一些大家的疑惑,一起走出索引的误区 误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的

分析Sql Server查询性能优化之走出索引的误区

误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的观点是错误的,SQL Server查询优化器是基于开销进行选择的优化器,通过一系列复杂判断来决定是否使用索引.使用什么类型索引.使用那个索引.SQL Server内部维护着索引列上的数据的统计,统计信息会随着索引列内容的变化而变化,索引的有效期完全取决于索引列上的统计信息,随着数据的变化关于索引的检索机制也随之变化.对于查询优化器来说始终保持查询开销最低始终是其的不二选择,如果一个非聚集索引的列上有大量的重复值,

Sql Server 查询性能优化之走出索引的误区分析

据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是,或者干脆把整个查询SQL直接发给DBA,让DBA直接帮忙优化了,所以造成的状况就是开发人员对于索引的理解.认识很局限,以下就把我个人对于索引的理解及浅薄认识和大家分享下,希望能解除一些大家的疑惑,一起走出索引的误区 误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的

SQL Server索引的使用和优化

    在应用系统中,尤其在联机事务处理系统中,对数据查询及处理速度已成为衡量应用系统成败的标准.而采用索引来加快数据处理速度也成为广大数据库用户所接受的优化方法. 在良好的数据库设计基础上,能有效地使用索引是SQL Server取得高性能的基础,SQL Server采用基于代价的优化模型,它对每一个提交的有关表的查询,决定是否使用索引或用哪一个索引.因为查询执行的大部分开销是磁盘I/O,使用索引提高性能的一个主要目标是避免全表扫描,因为全表扫描需要从磁盘上读表的每一个数据页,如果有索引指向数据

SQL Server数据库性能优化

设计1个应用系统似乎并不难,但是要想使系统达到最优化的性能并不是一件容易的事.在开发工具.数据库设计.应用程序的结构.查询设计.接口选择等方面有多种选择,这取决于特定的应用需求以及开发队伍的技能.本文以SQL Server为例,从后台数据库的角度讨论应用程序性能优化技巧,并且给出了一些有益的建议. 1 数据库设计 要在良好的SQL Server方案中实现最优的性能,最关键的是要有1个很好的数据库设计方案.在实际工作中,许多SQL Server方案往往是由于数据库设计得不好导致性能很差.所以,要实