下午，所有的SQL慢如牛。
平日里2-3秒搞定的SQL，这会非得弄个7-8秒。timeout更是频频爆出。搞得办公室怨叫声此起彼伏，真有点《生命协奏曲》的味道。
我是最听不得这些哀怨的，不仅仅是喊的难听，那些消极的声音，仿佛来自地狱的催命；更多是觉得，那是对我们这些DB Guy及其不友好的宣战啊。
DBA是公司最宝贵的资源，我们肯定调度过不来。索性自己上吧。还记得之前我说过的调优排错“三板斧”吗，今天又派上用场了。
第一板斧，找到谁在数据库上乱来。
幸好只是开发库，只有数量不多的连接，一查就知道，某个SQL发出了SOS的等待，占用大量的CPU，而且还在拼命的发出多线程请求。截获了它的SQL文本，拿出来一看，差点吓尿。
如此混乱的编码，换在平时，我可能都没兴趣看。poorman's formatter 这么好用的插件，估计这朋友对此一无所知。
好嘛，我帮你格式化下：
这回清晰多了。但各种缺陷也暴露无遗。很明显，会很慢。
丢到 SSMS 里面，足足等了69秒才出来数据。当时我的汗啊，这么慢的SQL在我的机器上发出，要被抓出来，不被大家给笑死。L 倒还是那个 L, 不过是 Laugh 罢了。（老读者一定知道 L 这个梗）
第二板斧，查看执行计划
排除那些复杂的 Index Spool，Stream Aggregation，这里面最吸引我的是同一张表，居然要扫描两次，就是那张 XXX_PER表。所以我不得不重新看下这段SQL的逻辑，简直是鬼才！
这种写法，大约就是“只有我看得懂的SQL，你们离不开我”的想法作祟下，搞出来的鬼。据我经验分析，往往都是刚出道的小聪明。
但凡看到我之前写过的文章 如何写好 5000 行的 SQL 代码，是绝对不可能写出这样的SQL。要么没懂重构的意义，要么就是甩小聪明。
所以，我做了些小调整：
把所有用到的列，都加到一个索引里面。再检查下执行计划
干净了，变快了。4秒，87426 条数据。18 倍的性能提升。当然，还有提升空间。
短暂的小插曲，每天都有。及时复盘，提高自己水平。
总结下，今天用到的技能：
1 - "三板斧"找端倪
2 - 三星索引好帮手
3 - 执行算子要常翻
