mysql sql优化实例1（force index使用）

今天和运维同窗一块查找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倍