Before & After：SQL整容级优化
首先说明这个优化有一定提升，但不是我所期望的
我接到一个涉及优化的SQL，具体内容实在太长。而且可能也不利于阅读。于是我脱敏以及简化一下。SQL中间大量的充斥着
(select 列名1
from t1
where t1.id = t2.id
) A,
(select 列名2
from t1
where t1.id = t2.id
) B,
(select 列名3
from t1
where t1.id = t2.id
) C,
这样的的形式，如果配合实际的列，实际的表。那就太长了。洋洋洒洒数百行。
SQL最后是用到索引的，所以本次不是给索引方向的优化。
就上面的SQL而言，我和对方说，你这个就是t1和t2关联，每一个字段都去关联循环一次，这样平白无故多做了很多次。其实把他放在一行一次性可以完成。这种时候一定要举例。
拿一个样品 A和B两个表
模拟原始写法是这样的
那么我给的改写建议是这样的
从这两个来说结果一致的，可以说基本是等效的。
那么看原始的执行效果
一共有三步access执行，最终发生了31次逻辑读。
而改写的执行效果
一共有两步access执行，最终发生了14次逻辑读。
毕竟我少一层括号。 而真实的SQL如果改写了，那么就不是一层，那是几十层了。
这背后的原因我是多少能猜出一点的
这些年站在开发角度看问题就习惯了。
就是需求提一个字段，加一个字段，那么就来一个括号。N表的联合，每次多一个也不方便动之前的，就加吧。流水线作业，铁打的代码流水的开发。今天做完这个，明天还不一定做什么呢？
还有不少企业是外包做，那么就是雇佣兵，明天还在不在这里还一说呢。只管完成眼前任务。
当进度和质量冲突时候，保证进度。进度是影响收入的，质量不是。
最终一定是有优化作用
毕竟少了几十个循环，一定是快了。而且SQL的篇幅是大幅降低。
当然还有一些其他方面的建议没有达成一致。其实很多时候去管管不着调的需求，能有更好的收益。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-3081276/ ，如需转载，请注明出处，否则将追究法律责任。
