可能很多大牛都知道這個方法，但我是頭回遇到，
因為專案原因，要寫很多查詢sql，對速度有要求，所以很注重sql語句的優化。
像使用left join 速度會快一些等等一些算是比較常見的方法吧。
近兩天做自測時發現了乙個問題，同樣一條語句，加了乙個條件竟然速度慢了那麼多，本身是乙個求彙總的sql語句，查全部單位的，和查一家單位的速度簡直差了好幾個級別，我記得好像是一分半鐘的速度，關聯了大概10多個表吧，這速度簡直慢的讓人髮指，是絕對不能接受，所以我開始找原因，
查詢同時有合計的sql ，我發現合計的sql速度很快，不到一秒就迅速的查出來了，而這條合計語句與之前那個語句水同的地方就是在原有語句的基礎 上又封裝了一層，所以，機智如我，在這條比較慢的語句也封裝了一層，果然，速度和合計的幾乎一樣快。至於為什麼會這樣，我還沒有查，不知道其中的原理。
對了，專案組有乙個技術比較好的人寫的sql也有這種情況，我之前還納悶為什麼要這樣多此一舉的寫，應該也是因為這樣寫速度比較快吧。
優化前大概意思是這樣：
select org_id , sum(amount) as amount ,max(in_date) as in_date.... from xx group by org_id
優化後大概是這樣：
select org_id sum(amount) as amount , max( in_date ) as in_date ..... from
( select org_id , sum(amount) as amount ,max(in_date) as in_date.... from xx group by org_id ) sm
group by org_id
記一次exists語句優化過程
我們經常會遇到帶有exists這種形式的語句，官方描述如下，一般對應於子查詢語句返回的布林值 在例子中可以看到 select department id from departments d where exists select from employees e where d.departmen...
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...
記一次新建操作（insert）的優化過程
mysql的 insert常用方法 插入後返回插入成功後的主鍵 insert paramtype object sql cdata insert into ucdp budget plan gmt create,gmt modified,biz date,status name,biz code,s...