共计 732 个字符，预计需要花费 2 分钟才能阅读完成。
问题
这是一个同行问的问题：有一张表，带一个联结索引，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/ref…
https://dev.mysql.com/doc/ref…
剩下的就是靠大家本人推理和试验取得论断：在这个 SQL 中，组合索引被用作 covering index，成为了全表扫描的替代品。
小贴士
如果大家在 MySQL 5.7 中做这个试验，会发现在 optimizer trace 中找不到相干信息。
MySQL 在 8.0 中对优化器信息的披露进行了加强。当前也举荐大家应用新版原本钻研个性，能取得更多的无效信息
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！