先抛一个核心结论：在 MySQL 5.7 中，联合索引一旦跳过首列，索引便会彻底失效，直接退化为全表扫描。原因很简单——InnoDB 的 B+ 树严格按 (a, b, c) 的字典序排序，整个索引的分支逻辑完全由第一列 a 驱动。换句话说，查询时只有带上 a 的值或范围，才能精确定位到某一段叶子节点。一旦跳过 a（比如只查 WHERE b = 'x'），引擎便无法处理：不同 a 下的 b 是交错存放的，b 在整个索引中并不具备全局有序性。因此根本无法从根节点“跳”到某个 b 对应的子树。
这与单列索引完全是两码事：INDEX(b) 的 B+ 树按 b 单独排序，可直接二分查找；而 INDEX(a,b) 中的 b 仅在自己所属的 a 分组内有顺序。一旦把 a 去掉，整棵索引树的排序规则随即失效。
联合索引在 MySQL 5.7 中跳过首列即失效，根源在于 B+ 树结构不支持跨列定位
此问题在 MySQL 5.7 中尤为突出，因为其优化器根本不具备主动探测首列值的能力。MySQL 8.0.13 引入的 skip_scan 机制，会枚举首列 a 的所有去重值（比如 a IN ('A','B','C')），然后对每个值构造等值条件，分别到索引里查找 b。但 5.7 的优化器完全没有这一选项，它的索引选择逻辑是原子性的——要么整条索引可用，要么索性不用，直接全表扫描。
实际中常见的错误现象包括：
EXPLAIN显示type: ALL，key: NULL- 查询耗时骤升，尤其在大表上表现明显
SHOW INDEX FROM tbl确认索引存在且字段顺序正确，但就是不走索引
不要指望靠改写 SQL（比如加 ORDER BY a 或 FORCE INDEX）让 5.7 “强行”用上跳过首列的联合索引——底层根本没有设计这条路。
MySQL 5.7 缺少 Index Skip Scan，优化器不会尝试绕过首列
既然底层不支持，那就只能顺着它的规则来。在 MySQL 5.7 环境下，没有捷径可走，必须显式适配索引匹配的规则：
- 如果高频查询是
WHERE b = ?，那就单独建立一个索引：ALTER TABLE t ADD INDEX idx_b (b) - 如果查询经常带上
c但总是缺少a，可以考虑改成INDEX(b, c)或INDEX(b, c, a)——把高频过滤列放到前面 - 不要指望用
OR、UNION或子查询来“欺骗”优化器复用到原联合索引，这些手段通常会带来更差的性能或额外临时表
还有一个坑：即使你把联合索引改成 (b, a, c)，只要业务查询仍然以 a 为主条件，又会出现问题——a 的选择性可能很低，导致索引效率反而下降。索引设计必须与实际 WHERE 模式对齐，不是简单地把字段塞进去就行。
最容易被忽略的一点：MySQL 5.7 不会主动告诉你“这个索引本来可以跳过首列使用，只是我不支持”，它只会沉默地选择全表扫描。因此你必须依靠 EXPLAIN 和慢日志主动去发现这类失效，别等线上报警了再手忙脚乱。
