。sql語句如下：
select distinct g.*, cp.name as cp_name, c.name as category_name, t.name as type_name fromgm_gameg left joingm_cpcp on cp.id = g.cp_id and cp.deleted = 0 left joingm_categoryc on c.id = g.category_id and c.deleted = 0 left joingm_typet on t.id = g.type_id and t.deleted = 0 where g.deleted = 0 order by g.modify_time desc limit 20 ;
【問題分析】
【優化方案】
第一條語句：查詢符合條件的資料，只需要查詢g.id即可
select distinct g.id
fromgm_gameg left joingm_cpcp on cp.id = g.cp_id and cp.deleted = 0 left joingm_categoryc on c.id = g.category_id and c.deleted = 0 left joingm_typet on t.id = g.type_id and t.deleted = 0 where g.deleted = 0 order by g.modify_time desc limit 20 ;
cp.name as cp_name,c.name as category_name,t.name as type_name fromgm_gameg left joingm_cpcp on cp.id = g.cp_id and cp.deleted = 0 left joingm_categoryc on c.id = g.category_id and c.deleted = 0 left joingm_typet on t.id = g.type_id and t.deleted = 0 where g.deleted = 0 and g.id in(…………………) order by g.modify_time desc ;
【實測效果】
在ssd機器上測試，優化前大約需要7s，優化後第一條0.3s，第二條0.1s，優化後執行速度是原來的10倍以上，io從100%降到不到1%
可以看出，優化前磁碟io是效能瓶頸，ssd的速度要比sata明顯要快，優化後磁碟不再是瓶頸，ssd和sata效能沒有差別。
【理論分析】
使用臨時表進行效能優化
這兩個月都在搞一儲存過程，快要被它搞出精神病了。主要是它執行的時間比較長，每次執行幾十分鐘是常有的事，幾個小時也不少見。甚至乎這幾天，執行了兩天一夜都還不知道何時會圓滿結束。等待本來就是乙個痛苦的過程，而這個過程要幾天幾夜，那我不瘋誰人瘋。這肯定是有問題的。執行時間超過1小時的都應該有問題。後來，改...
SQL語句建立臨時表
1.insert into select語句 語句形式為 insert into table2 field1,field2,select value1,value2,from table1 要求目標表table2必須存在，由於目標表table2已經存在，所以我們除了插入源表table1的字段外，還可...
MySql優化sql語句效能
一.優化方面 可以從下面2個方面進行優化 1.減少io次數 2.減少cpu計算次數 二.常見sql命令誤區 1.count 1 和count primary key 優於 count 實際上count 計算操作做了優化 2.select a,b from 比 select a,b,c from 可以...