sql優化例項

2021-09-17 23:33:33 字數 1144 閱讀 9302

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...