SQL书签查找小记

　　前两天，公司一个KPI方面的系统被最终用户Complain了：系统页面越来越慢，中间的圈越转越多了！

　　说明下：系统是B/S架构的，页面等待，跳转时设置了一个Loading图标（就是用户说的圈），圈转的次数越来越多，说明系统的性能越来越差，页面响应时间逐渐增多。

　　受不了用户的抱怨，再者想查查到底哪里出了问题，省的被老板鄙视，就抽了点时间从系统前端到后台SQL处理都清查了一遍，发现问题出在一个存储过程身上，当然是别人写的了！

　　分析这个存储过程（以上简称SP），发现其主要使用一个View来查询，而这个View是由两个Table来生成的，其中一个Table的数据量当时是250w笔。再进一步分析查询语句，SP是使用View直接查询的，传入些where条件，看起来没问题；再看看View内部的SQL语句，发现用了5个union，单独执行后一个语句（暂不使用union），用时一般为9s，根据条件不同，有的甚至达到11s，纳闷啊，崩溃啊，为什么会如此！！系统上线时，页面响应非常及时啊，查……

　　在查询分析器找打开执行计划和IO统计，仔细看看其执行过程：SQL查询中，where条件都已建立了index，也有主键，但在返回的栏位中，有几个是不包括在index中的-------典型的书签查找啊！在数据量少的时候，SQL执行引擎自动根据其使用条件进行了优化，但随着数据量的持续增大，性能瓶颈就逐渐突出了。

　　碰巧前段时间看了博文Sql Server查询性能优化之不可小觑的书签查找，分析后直接优化，在一个已有的index中添加include命令，将那几个多出的栏位添加进去，生成index后，执行查询，速度刚刚的，不到1s……

　　再看看更改index后对Table的影响：Table总大小约为450M，index大小为150M左右，include对其影响较少，是之前DBA建立的index占用的多。为了改善系统响应时间，只能用空间换时间了，后续将Table数据做备份，清理就好了！

　　通知用户，满意！汇报给老板，也满意----只说结果，不究过程！

　　说了这么多，目的有二：

　　一，记录下之前被自己忽略的技术债务---没有考虑到数据量的严重性及对SQL查询的持续优化！

　　二，作为教训分享出来给大伙提个醒，也再次顶下懒惰的肥兔，他的SQL优化类博文经典、有用，哈……

　　PS：这篇随笔是在家里写的，但系统环境在公司，无法截图来更形象的说明了，抱歉！！