1.盡量不生成子表或者將子表的資料量控制到最小(子表只能順序讀取,沒有任何索引)
原有sql
from
(select task_id, user_id from mtcrm_task.item where status = 0 and is_deleted = 0 and is_archived = 0) item
left join
(select id, status from mtcrm_task.task where status = 1 and is_deleted = 0 ) task
on item.task_id = task.id
group by item.user_id
生成大量子表,而且因為left join 的原因有很多錯誤資料。(正常應該是inner join)
修改後select item.user_id from mtcrm_task.item item
, mtcrm_task.task task
where item.status = 0 and item.is_deleted = 0 and item.is_archived = 0
and task.status = 1 and task.is_deleted = 0
and item.task_id = task.id
group by item.user_id
相當於 inner join
也等同於
select item.user_id from mtcrm_task.item item
left join mtcrm_task.task task
on item.task_id = task.id
where item.status = 0 and item.is_deleted = 0 and item.is_archived = 0
and task.status = 1 and task.is_deleted = 0
group by item.user_id
explain 看一下發現使用了索引
分析執行順序 todo @胡曉婕 感覺是先執行 where,結果才group by ,而結果是乙個臨時表
優化效果
30-70m -> 1s內
sql 查詢優化例項
語句1 select account.alias,sum amount from expense,account where date 20101101 and date 20101131 and expense.act id account.act id group by expense.act ...
SQL優化例項 思路分析
一sql優化思路 乙個真實具體的sql優化思路 一般都看預估的執行計畫,比如遇到乙個sql執行計畫很長,很複雜,從計畫中沒有看到返回行數多,cost高或連線方式錯誤的地方,沒有明顯瓶頸,但整體邏輯讀很高,執行很慢。這時就可以去看真實的執行計畫,並檢視真實計畫裡邏輯讀cr最多的步驟。可以做個10046...
SQL開發例項和優化
找出連續的資料 如1,2,3,48,50,51,52,53,67,68 找出連續的數字的起點和重點 1,348,48 51,53 67,68 create table test.range problem a int not null,primary key a insert into test.r...