今天和运维同学一块查找mysql慢查询日志，发现了如下一条sql:
SELECT sum(`android` + ios) total,pictureid,title,add_time FROM `juzi_access_statistic` LEFT JOIN juzi_news ON juzi_access_statistic.pictureid=juzi_news.id GROUP BY `pictureid` HAVING total >= 100000 AND pictureid >= 8092 AND title IS NOT NULL LIMIT 2;
该sql语句花费了 2.7s，那么总共多少条呢？
总共54万条记录，其实也不算太慢，但是我觉得应该有很大的优化空间。
一：先看一下表结构
CREATE TABLE `juzi_access_statistic` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`pictureid` int(11) NOT NULL DEFAULT '0' COMMENT '文章id',
`date` date NOT NULL COMMENT '日期',
`ios` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '苹果app访问量',
`android` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '安卓app访问量',
PRIMARY KEY (`id`),
UNIQUE KEY `pictureid` (`date`,`pictureid`) USING BTREE,
KEY `indexpictureid` (`pictureid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=‘访问统计表’;
二： 查看一下执行计划
在这里我发现了问题：juzi_access_statistic表竟然是全表扫描,pictureid字段上存在索引，为什么没有使用上呢？
我个人觉得原因是：因为存在条件pictureid >= 8092 和 juzi_access_statistic.pictureid=juzi_news.id（等价传递），所以mysql觉得使用juzi_news表的主键id查询效率是最高的。
三：使用force index 优化
看到效果了吧：key字段显示使用到了pictureid字段的索引，但扫描的行没有减少，执行时间如下：
四：正确使用where
以上sql中的pictureid >= 8092 其实应该放到where子句中，以便过滤到更多的无用记录，修复后的执行计划如下：
效果也很明显：rows减少到不足10万，速度可想而知，见下图：
从开始的2.74s 优化到17ms, 优化了100倍