今天和運維同學一塊查找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倍