跳过联合索引中间列会导致后续字段失效，因为b+树仅在前导列值完全相等时保证后续列有序；缺失中间列后，后续列在物理存储中不再连续可定位，无法通过索引直接查找，只能回表过滤。
为什么跳过联合索引中间列会让后续字段失效
因为B+树只保证“前导列值完全相等”前提下的后续列有序。一旦中间列缺失，MySQL就无法维持这个前提，后续列在物理存储上不再连续可定位。
比如索引 INDEX (a, b, c)，数据按 a 排序，a 相同时再按 b 排序，b 也相同时再按 c 排序。这种嵌套顺序是树结构的硬约束。
当查询写成 WHERE a = 1 AND c = 'x' 时，MySQL能快速定位所有 a = 1 的数据块，但这些块里 c 的值是散落在不同 b 分组中的（比如 b=2 下有 c='x'，b=5 下也有 c='x'），根本没法用索引直接跳到目标 c 值。
- 这不是优化器“没尽力”，而是B+树本身不支持跨分组的二级排序跳转
-
EXPLAIN中key_len会明显变小（比如只算到a的长度），说明c没参与索引查找 -
Extra字段若出现Using where，基本等于确认c = 'x'是回表后逐行过滤的
哪些写法看似合理实则无效
很多人试图用语法变形绕过中间列缺失的问题，但几乎都失败了，因为没动底层结构。
- 把
WHERE a = 1 AND c = 'x'改成WHERE a = 1 AND b IS NULL AND c = 'x'：除非b真的大量为NULL且业务允许，否则只是增加判断开销，c还是不能走索引 - 加
FORCE INDEX：它只告诉优化器“用这个索引”，但不改变索引内部怎么查——b缺失，c就依然不可定位 - 用
ORDER BY a, c或GROUP BY a, c：排序和分组字段不连续，照样触发Using filesort或临时表
真正管用的解法只有两个方向
要么调整索引设计，要么拆分查询意图，没有第三条路。
- 建更窄的专用索引：比如高频查
a和c，就单独建INDEX (a, c)；高频查b和c，就另建INDEX (b, c) - 把等值高频列左移：如果
c实际上比b更常用于等值过滤，索引应优先考虑INDEX (a, c, b)而不是硬塞b在中间 - 避免强求“一索引覆盖全部”：联合索引不是万能收纳盒，字段堆得越多，越容易因某一个查询模式破坏整体有效性
怎么快速验证中间列是否真被跳过
别只看 EXPLAIN 的 key 字段是否显示索引名，关键盯两个指标：
-
key_len：对照索引定义算各字段理论字节数（如INT是 4 字节，VARCHAR(50)在utf8mb4下最多 200 字节），就能反推出实际用了几列 -
Extra是否含Using index：如果写了SELECT a, c FROM t WHERE a = 1 AND c = 'x'，但Extra是Using where，说明c没走索引，只是过滤条件
最麻烦的是那种“看起来走了索引，其实只用了一半”的情况——key_len 对不上、Extra 有歧义，这时候必须结合实际执行时间和 profiling 数据交叉验证。
