首先說明這個優化有一定提升，但不是我所期望的
我接到一個涉及優化的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的篇幅是大幅降低。
當然還有一些其他方面的建議沒有達成一致。其實很多時候去管管不著調的需求，能有更好的收益。
)
