移动下SQL中的表位置，性能提高18倍

下午，所有的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 - 执行算子要常翻

本文转载自网络，原文链接：https://mp.weixin.qq.com/s/53RtAEpXkzkP2nBCFU8McQ
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！