優化案例 | CASE WHEN進行SQL改寫優化
導讀
今天給大家分享一個通過SQL改寫而獨闢蹊徑的SQL優化案例
待優化場景
發現SLOW QUERY LOG中有下面這樣一條記錄：
... # Query_time: 59.503827 Lock_time: 0.000198 Rows_sent: 641227 Rows_examined: 13442472 Rows_affected: 0 ... select uid,sum(power) powerup from t1 where date>='2017-03-31' and UNIX_TIMESTAMP(STR_TO_DATE(concat(date,' ',hour),'%Y-%m-%d %H'))>=1490965200 and UNIX_TIMESTAMP(STR_TO_DATE(concat(date,' ',hour),'%Y-%m-%d %H'))<1492174801 and aType in (1,6,9) group by uid;
實話說，看到這個SQL我也忍不住想罵人啊，究竟是哪個腦殘的XX狗設計的？
竟然把日期時間中的 date 和 hour 給獨立出來成兩列，查詢時再合併成一個新的條件，簡直無力吐槽。
吐槽歸吐槽，該幹活還得幹活，誰讓咱是DBA呢，SQL優化是咱的拿手好戲不是嘛~
SQL優化之路
SQL優化思路
不厭其煩地再說一遍SQL優化思路。
想要優化一個SQL，一般來說就是先看執行計劃，觀察是否儘可能用到索引，
同時要關注預計掃描的行數，
以及是否產生了臨時表（Using temporary） 或者
是否需要進行排序（Using filesort），
想辦法消除這些情況。
SQL效能瓶頸定位
毫無疑問，想要優化，先看錶DDL以及執行計劃：
CREATE TABLE `t1` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `date` date NOT NULL DEFAULT '0000-00-00', `hour` char(2) NOT NULL DEFAULT '00', `kid` int(4) NOT NULL DEFAULT '0', `uid` int(11) NOT NULL DEFAULT '0', `aType` tinyint(2) NOT NULL DEFAULT '0', `src` tinyint(2) NOT NULL DEFAULT '1', `aid` int(11) NOT NULL DEFAULT '1', `acount` int(11) NOT NULL DEFAULT '1', `power` decimal(20,2) DEFAULT '0.00', PRIMARY KEY (`id`,`date`), UNIQUE KEY `did` (`date`,`hour`,`kid`,`uid`,`aType`,`src`,`aid`) ) ENGINE=InnoDB AUTO_INCREMENT=50486620 DEFAULT CHARSET=utf8mb4 /*!50500 PARTITION BY RANGE COLUMNS(`date`) (PARTITION p20170316 VALUES LESS THAN ('2017-03-17') ENGINE = InnoDB, PARTITION p20170317 VALUES LESS THAN ('2017-03-18') ENGINE = InnoDB ... [email protected][myDB]> EXPLAIN select uid,sum(power) powerup from t1 where date>='2017-03-31' and UNIX_TIMESTAMP(STR_TO_DATE(concat(date,' ',hour),'%Y-%m-%d %H'))>=1490965200 and UNIX_TIMESTAMP(STR_TO_DATE(concat(date,' ',hour),'%Y-%m-%d %H'))<1492174801 and aType in (1,6,9) group by uid\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t1 partitions: p20170324,p20170325,....all partition type: ALL possible_keys: did key: NULL key_len: NULL ref: NULL rows: 25005577 filtered: 15.00 Extra: Using where; Using temporary; Using filesort
明顯的，這個SQL效率非常低，全表掃描、沒有索引、有臨時表、需要額外排序，什麼倒黴催的全趕上了。
優化思考
這個SQL是想統計符合條件的power列總和，雖然 date 列已有索引，但WHERE子句中卻對 date 列加了函式，而且還是 date 和 hour 兩列的組合條件，那就無法用到這個索引了。
還好，有個聰明伶俐的妹子，突發起想（事實上這位妹子本來就擅長做SQL優化的~），可以用 CASE WHEN 方法來改造下SQL，改成像下面這樣的：
select uid,sum(powerup+powerup1) from
(
select uid,
case when concat(date,' ',hour) >='2017-03-24 13:00' then power else '0' end as powerup,
case when concat(date,' ',hour) < '2017-03-25 13:00' then power else '0' end as powerup1
from t1
where date>='2017-03-24'
and date <'2017-03-25'
and aType in (1,6,9)
) a group by uid;是不是很有才，直接把這個沒辦法用到索引的條件給用CASE WHEN來改造了。看看新的SQL執行計劃：
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
partitions: p20170324
type: range
possible_keys: did
key: idx2_date_addRedType
key_len: 4
ref: NULL
rows: 876375
filtered: 30.00
Extra: Using index condition; Using temporary; Using filesort看看這個SQL的執行代價：
+----------------------------+---------+
| Variable_name | Value |
+----------------------------+---------+
| Handler_read_first | 1 |
| Handler_read_key | 1834590 |
| Handler_read_last | 0 |
| Handler_read_next | 1834589 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 232276 |
| Handler_read_rnd_next | 232277 |
+----------------------------+---------+及其SLOW QUERY LOG記錄的資訊：
# Query_time: 6.381254 Lock_time: 0.000166 Rows_sent: 232276 Rows_examined: 2299141 Rows_affected: 0
# Bytes_sent: 4237347 Tmp_tables: 1 Tmp_disk_tables: 0 Tmp_table_sizes: 4187168
# InnoDB_trx_id: 0
# QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Tmp_table_on_disk: No
# Filesort: Yes Filesort_on_disk: No Merge_passes: 0
# InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000
# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
# InnoDB_pages_distinct: 9311看起來還不是太理想啊，雖然不再掃描全表了，但畢竟還是 有臨時表 和 額外排序，想辦法消除後再對比看下。
有個變化不知道大家注意到沒，新的SLOW QUERY LOG記錄多了不少資訊，這是因為用了Percona分支版本的外掛才支援，這個功能確實不錯，甚至還能記錄Profiling的詳細資訊，強烈推薦。
我們新建個 uid 列上的索引，看看能除臨時表及排序後的代價如何，看看這個的開銷會不會更低。
[email protected][myDB]> ALTER TABLE t1 ADD INDEX idx_uid(uid);
[email protected][myDB]> EXPLAIN select uid,sum(powerup+powerup1) from
(
select uid,
case when concat(date,' ',hour) >='2017-03-24 13:00' then power else '0' end as powerup,
case when concat(date,' ',hour) < '2017-03-25 13:00' then power else '0' end as powerup1
from t1
where date>='2017-03-24'
and date <'2017-03-25'
and aType in (1,6,9)
) a group by uid\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: if_date_hour_army_count
partitions: p20170331,p20170401...
type: index
possible_keys: did,idx_uid
key: idx_uid
key_len: 4
ref: NULL
rows: 12701520
filtered: 15.00
Extra: Using where看看新增索引後SQL的執行代價：
+----------------------------+---------+
| Variable_name | Value |
+----------------------------+---------+
| Handler_read_first | 1 |
| Handler_read_key | 1 |
| Handler_read_last | 0 |
| Handler_read_next | 1834589 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 0 |
+----------------------------+---------+及其SLOW QUERY LOG記錄的資訊：
# Query_time: 5.772286 Lock_time: 0.000330 Rows_sent: 232276 Rows_examined: 1834589 Rows_affected: 0
# Bytes_sent: 4215071 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# InnoDB_trx_id: 0
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
# Filesort: No Filesort_on_disk: No Merge_passes: 0
# InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000
# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
# InnoDB_pages_distinct: 11470我們注意到，雖然加了 uid 列索引後的SQL掃描的data page更多了，但執行效率其實是更高的，因為消除了 臨時表 和 額外排序，這從 Handlerread% 的結果中也能看出來，很顯然它的順序I/O更多，隨機I/O更少，所以雖然需要掃描的 data page 更多，實際上效率卻是更快的。
後記
再想想這個SQL還有優化空間嗎，顯然是有的，那就是把資料表重新設計，將 date 和 hour 列整合到一起，這樣就不用費勁的拼湊條件並且也能用到索引了。
最後安利下，知數堂培訓馬上推出 SQL開發優化 課程，由業界資深SQL優化專家鄭老師授課。
該課程關鍵字：MySQL、Oracle、SQL調優、EXPLAIN、DBMS_XPLAN、OPTIMIZER TRACE、SQL改寫、NESTED LOOP、OUTER JOIN、HASH JOIN、ERD圖、HINT、SORT MERGE、Materialized View、ROWNUM。
學完本課程，無論您是DBA工程師、運維工程師，還是開發工程師，抑或系統架構師、技術主管，都將大幅增強您的職場實力，加薪50%輕輕鬆鬆。此外，我們也會將優秀的學員直接推向各大一線網際網路公司。
本週四晚上鄭老師還會再進行一次公開課分享，講講GROUP BY的用法及堵門優化技巧。
有興趣的同學可以掃碼加入知數堂QQ群 579036588 關注課程進展。
不再加原創
喜歡就轉發
打賞可勾搭
靠譜好茶&線上培訓，都在〖老葉茶館〗http://yejinrong.com