第34问:我没有让 SQL 使用联合索引,但它不听 - 技术分享 - 新闻资讯 - 爱可生

第34问:我没有让 SQL 使用联合索引,但它不听

发布时间:2021-04-13 浏览次数:218

这是一个同行问的问题:有一张表,带一个联合索引,SQL 不满足最左匹配,为什么执行计划显示能用到这个联合索引?

叨叨叨

有经验的 DBA 此刻已经知道原因了。

本文立意主要是介绍诊断的方法,方便大家在没有相关知识时找到线索。

实验

起手先来个数据库:


造个表:


看一下执行计划:


看上去确实有点怪,

我们来分析一下:这个 SQL 不满足索引的最左匹配的原则(跳过了 b 列,直接使用 c 列),不应该选择联合索引。但执行计划确实选择了联合索引,可能是优化器在起作用。

我们在 实验 27 中介绍过如何诊断优化器的使用,这里我们再来用一次:


trace 结果比较长,我们将其放在一个 json 的图形化工具中,然后查找索引的名字 xx,可以找到以下条目:


可以看到,MySQL 认为:

  • 联合索引是最优的 covering index

  • 联合索引可能是 range index

继续搜索:


可以看到,MySQL 由于代价原因,没有选择联合索引作为 skip scan。

这里涉及了三个概念:covering index、range index、skip scan,我们可能不知道这些概念是什么,稍加搜索就可以获得官方文档的帮助:

https://dev.mysql.com/doc/refman/8.0/en/range-optimization.html#range-access-skip-scan

https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_covering_index

剩下的就是靠大家自己推理和实验获得结论:在这个 SQL 中,组合索引被用作 covering index,成为了全表扫描的替代品。

小贴士

如果大家在 MySQL 5.7 中做这个实验,会发现在 optimizer trace 中找不到相关信息。

MySQL 在 8.0 中对优化器信息的披露进行了增强。以后也推荐大家使用新版本来研究特性,能获得更多的有效信息。

关键字:MySQL监测MySQL监控MySQL监控工具

相关推荐

产品试用 产品试用
400-820-6580 免费电话