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倍