今天给大家分享一个通过SQL改写而独辟蹊径的SQL优化案例。
发现SLOW QUERY LOG中有下面这样一条记录：
实话说，看到这个SQL我也忍不住想骂人啊，究竟是哪个脑残的XX狗设计的？
竟然把日期时间中的 date 和 hour 给独立出来成两列，查询时再合并成一个新的条件，简直无力吐槽。
吐槽归吐槽，该干活还得干活，谁让咱是DBA呢，SQL优化是咱的拿手好戏不是嘛~
不厌其烦地再说一遍SQL优化思路。
想要优化一个SQL，一般来说就是先看执行计划，观察是否尽可能用到索引，同时要关注预计扫描的行数，以及是否产生了临时表（Using temporary） 或者 是否需要进行排序（Using filesort），想办法消除这些情况。
毫无疑问，想要优化，先看表DDL以及执行计划：
明显的，这个SQL效率非常低，全表扫描、没有索引、有临时表、需要额外排序，什么倒霉催的全赶上了。
这个SQL是想统计符合条件的power列总和，虽然 date 列已有索引，但WHERE子句中却对 date 列加了函数，而且还是 date 和 hour 两列的组合条件，那就无法用到这个索引了。
还好，有个聪明伶俐的妹子，突发起想（事实上这位妹子本来就擅长做SQL优化的~），可以用 CASE WHEN 方法来改造下SQL，改成像下面这样的：
是不是很有才，直接把这个没办法用到索引的条件给用CASE WHEN来改造了。看看新的SQL执行计划：
看看这个SQL的执行代价：
及其SLOW QUERY LOG记录的信息：
看起来还不是太理想啊，虽然不再扫描全表了，但毕竟还是有临时表和额外排序，想办法消除后再对比看下。
有个变化不知道大家注意到没，新的SLOW QUERY LOG记录多了不少信息，这是因为用了Percona分支版本的插件才支持，这个功能确实不错，甚至还能记录Profiling的详细信息，强烈推荐。
我们新建个 uid 列上的索引，看看能除临时表及排序后的代价如何，看看这个的开销会不会更低。
看看添加索引后SQL的执行代价：
我们注意到，虽然加了 uid 列索引后的 SQL 扫描的 data page 更多了，但执行效率其实是更高的，因为消除了临时表和额外排序，这从 Handlerread% 的结果中也能看出来，很显然它的顺序I/O更多，随机I/O更少，所以虽然需要扫描的 data page 更多，实际上效率却是更快的。
再想想这个SQL还有优化空间吗，显然是有的，那就是把数据表重新设计，将 date 和 hour 列整合到一起，这样就不用费劲的拼凑条件并且也能用到索引了。