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

Posted 爱叨叨的程序狗

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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临时表产生的执行效率问题改进(转)》

以上是关于MySQL执行计划误选索引及修改方案的主要内容,如果未能解决你的问题,请参考以下文章

不是吧!MySQL 竟然会选错索引

Spark SQL CBO 基于代价的优化

MySQL索引及执行计划

MySQL学习第七篇索引管理及执行计划

MySQL 索引管理及执行计划

Mysql之B+树索引实战