优化案例 | 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以及执行计划：