这是一个同行问的问题：有一张表，带一个联合索引，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 中对优化器信息的披露进行了增强。以后也推荐大家使用新版本来研究特性，能获得更多的有效信息。