一下午，所有的SQL都慢得跟牛一样。平时2-3秒搞定的SQL，现在要7-8秒。经常超时。弄得office一个接一个的抱怨，真的有点《生命协奏曲》。我最听不到这些委屈，不仅叫喊难听，那些消极的声音也仿佛是从地狱里催促的；而且，我觉得这是对我们DBGuys及其不友好行为的宣战。DBA是公司最宝贵的资源，我们肯定管不了。自己动手就行了。记得之前说过的调优排错“三招”，今天又派上用场了。第一个技巧是找出谁在乱动数据库。幸运的是，它只是一个开发库，只有少量的连接。查了一下，得知是某条SQL发出了SOS等待，占用了很多CPU，还在拼命的向外发送多线程请求。我截取了它的SQL文本，拿出来一看，吓尿了。这么扑朔迷离的代码，平时我可能没兴趣看。Poorman'sformatter这么好用的插件，估计这位朋友一无所知。好吧，让我为你格式化一下：这次清楚多了。但也暴露出各种破绽。显然，它会很慢。扔进SSMS，整整69秒，数据才出来。当时我满头大汗，这么慢的SQL发到我的机器上，我都快被抓出来了，大家别笑死了。L还是那个L，只是笑。（老读者一定知道L的梗。）第二个技巧是检查执行计划，排除那些复杂的IndexSpool和StreamAggregation。最吸引我的是同一张表，要扫描两次，也就是XXX_PER表。于是只好重新看了一下这个SQL的逻辑，真是天才！这样的写法大概是“只有我懂SQL，你离不开我”的想法的结果。根据我的经验分析，他们往往是刚出道的聪明人。但是如果你看了我之前写的文章，5000行的SQL代码怎么写，是绝对不可能写出这样的SQL的。要么他们不明白重构的意义，要么他们很聪明。因此，我做了一些小调整：将所有使用的列添加到索引中。再次检查执行计划是否干净且速度更快。4秒，87426条数据。18倍的性能提升。当然，还有改进的余地。简短的情节，每天。及时复习，提高自己的水平。总结一下，今天用到的技巧：1——“三招”找线索2——三星索引好帮手3——执行算子要经常翻
