mysql索引不生效的解决方法

公司服务用的mysql，最近在查询时时间很慢，经常会上10多秒，查看了一下查询的执行计划，发现索引没有生效。

存储引擎使用InnoDB。

 一开始在主库查询，一直很好奇为什么索引不生效，切换到备库之后，发现备库是有效的。

开始考虑是不是因为索引出问题，后对索引重建，发现效率高了不少。

 简单记录一下对比。

mysql> explain select * from runinfo where status in (0, 2, 1, 3, 4, 7, 9, 10);
+----+-------------+---------+-------+---------------+------+---------+------+----------+-------------+
| id | select_type | table   | type  | possible_keys | key  | key_len | ref  | rows     | Extra       |
+----+-------------+---------+-------+---------------+------+---------+------+----------+-------------+
|  1 | SIMPLE      | runinfo | All   | status_2      | NULL | NULL    | NULL |  2378055 | Using where |
+----+-------------+---------+-------+---------------+------+---------+------+----------+-------------+
row in set (0.00 sec)

上面是主库的执行计划。

BJXSHOP网上购物系统 - 书店版

BJXSHOP购物管理系统是一个功能完善、展示信息丰富的电子商店销售平台；针对企业与个人的网上销售系统；开放式远程商店管理；完善的订单管理、销售统计、结算系统；强力搜索引擎支持；提供网上多种在线支付方式解决方案；强大的技术应用能力和网络安全系统 BJXSHOP网上购物系统 - 书店版，它具备其他通用购物系统不同的功能，有针对图书销售而进行开发的一个电子商店销售平台，如图书ISBN，图书目录

下载

 对比一下备库的执行计划。

mysql> explain select * from runinfo where status in (0, 2, 1, 3, 4, 7, 9, 10);
+----+-------------+---------+-------+---------------+----------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key      | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-------------+
|  1 | SIMPLE      | runinfo | range | status_2      | status_2 | 4       | NULL |  116 | Using where |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-------------+
row in set (0.00 sec)

 可以看出，备库在查询时适应到索引 status_2。

 执行如下的命令之后，问题解决。

mysql> OPTIMIZE TABLE runinfo;
+------------------+----------+----------+-------------------------------------------------------------------+
| Table            | Op       | Msg_type | Msg_text                                                          |
+------------------+----------+----------+-------------------------------------------------------------------+
| schedule.runinfo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| schedule.runinfo | optimize | status   | OK                                                                |
+------------------+----------+----------+-------------------------------------------------------------------+
rows in set (47.13 sec)

第二天来看，查询再一次变慢，有点好奇是不是有新数据写入导致索引不更新。