MySQL执行计划误选索引及修改方案

MySQL的优化器

MySQL在执行查询语句时使用那个索引是由server层的优化器决定的。优化器的作用是找到一个最优的执行方案，用最小的代价去执行语句。由于MySQL使用预估的方式去选择索引，所以MySQL可能会出现选择索引出错的情况，无法命中最优索引。

优化器考虑因素

1. 扫描行数
2. 是否使用临时表
3. 是否需要排序

扫描行数

MySQL在执行查询语句前，并不会知道准确的查询行数，因此它会使用统计信息来预估行数。当执行计划中出现扫描行数与实际情况出入较大的误差时，可以使用analyze table table_name来重新统计索引信息。

统计信息就是索引的区分度，一个索引上不同的值越多，区分度越大，对于查询来说，区分度越大越好。

当查询字段中含有索引时，MySQL却选择不使用索引，原因可能是：MySQL对比使用索引时，回表操作所耗费的时间、资源比扫描全表更大，因此选择全表扫描。

临时表

MySQL中可以使用explain查看执行计划，执行计划中Extra列出现Using temporary即使用了临时表。一般情况下使用到临时表意味着性能较低，在开发时应尽量避免使用临时表。

使用临时表的场景：

1）ORDER BY子句和GROUP BY子句不同， 例如：ORDERY BY price GROUP BY name；
2）在JOIN查询中，ORDER BY或者GROUP BY使用了不是第一个表的列 例如：SELECT * from TableA, TableB ORDER BY TableA.price GROUP by TableB.name
3）ORDER BY中使用了DISTINCT关键字 ORDERY BY DISTINCT(price)
4）SELECT语句中指定了SQL_SMALL_RESULT关键字 SQL_SMALL_RESULT的意思就是告诉MySQL，结果会很小，请直接使用内存临时表，不需要使用索引排序 SQL_SMALL_RESULT必须和GROUP BY、DISTINCT或DISTINCTROW一起使用 一般情况下，我们没有必要使用这个选项，让MySQL服务器选择即可。

是否需要排序

CREATE TABLE `t` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `a` (`a`),
  KEY `b` (`b`)
) ENGINE=InnoDB;

explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;

查看该语句，where条件中a需要扫描1000行，b要扫描50000行，由于两者是and条件连接，所以我们认为使用索引a可以扫描更少的行数，因此，在查询时优化器会使用到a索引，但是使用explain执行时，可以看到explain命中了b索引，扫描了50128行。

命中索引b的原因是：查询语句中含有order by b，由于索引有排序的功能，优化器认为使用b索引可以避免再次排序，所以使用了索引b。

当某个字段需要排序的时候，那么同等条件下，会优先考虑使用排序的那个字段索引，因为直接使用排序字段做索引，查询的结果就是已经排好序的，无需再次排序。

纠正优化器处理方案

1. 使用force index强行指定索引，MySQL不再评估其他索引的执行代价
2. 修改SQL语句，引导MySQL使用期望的索引
3. 在某些场景下新建一个更合适的索引，或删除误用索引。

参考资料

• 《MySQL实战45讲 | 极客时间 | 丁奇》
• 《mysql临时表产生的执行效率问题改进(转)》