问题
这是一个同行问的问题：有一张表，带一个联合索引，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 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
