联合索引只认最左前缀，因B+树必须从最左列连续匹配；跳过中间列（如索引(a,b,c)中WHERE a=1 AND c=3）则右侧列失效，导致key为NULL或key_len偏小。
联合索引为什么只认最左前缀
MySQL 的 B+ 树索引结构决定了它只能从索引定义的最左侧列开始连续匹配。一旦跳过某列（比如 WHERE a = 1 AND c = 3，而索引是 (a, b, c)），中间的 b 没出现，c 就无法走索引——不是“优化器不聪明”，而是 B+ 树根本没法跳着定位。
常见错误现象：EXPLAIN 显示 key_len 值偏小、type 是 range 或 index 但实际扫描行数远超预期；或者加了索引却没生效，key 列为 NULL。
- 索引
(a, b, c)能加速WHERE a = 1、WHERE a = 1 AND b > 5、WHERE a = 1 AND b = 2 AND c BETWEEN 10 AND 20 - 但对
WHERE b = 2、WHERE c = 3、WHERE a = 1 AND c = 3（缺b）完全无效 - 如果查询里有
ORDER BY b, c，而索引是(a, b, c)，且a条件是等值（=），那排序可复用索引；若a是范围（>），则排序失效，会触发Using filesort
如何调整 WHERE 条件顺序来触发联合索引
条件顺序本身不影响优化器判断，真正起作用的是「哪些列参与了等值或范围过滤」以及「是否连续从左开始」。但人为调整写法，能帮自己和同事快速识别缺失的驱动列。
使用场景：已有索引 (user_id, status, created_at)，但业务查询常写成 WHERE status = 'active' AND created_at > '2024-01-01' —— 这条语句永远用不上该索引。
- 必须补上
user_id条件，哪怕它是动态传入的IN列表，如WHERE user_id IN (101, 102, 105) AND status = 'active' - 如果
user_id确实未知（比如后台查所有 active 订单），那就别硬套这个索引，应单独建(status, created_at)索引 - 避免在索引列上用函数或计算，例如
WHERE DATE(created_at) = '2024-01-01'会让created_at失效；改用WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'
ORDER BY 和 GROUP BY 怎么配合联合索引下推
当 ORDER BY 字段能被联合索引最左连续覆盖，且 WHERE 过滤后剩余数据已按该顺序物理存储时，MySQL 才能跳过排序步骤。这比单纯“加索引”更苛刻。
参数差异：是否使用索引排序，取决于 WHERE 条件是否“锁住”了索引前缀。例如索引 (a, b, c)：
-
WHERE a = 1 ORDER BY b, c✅ 可跳排序 -
WHERE a > 1 ORDER BY b, c❌a是范围，b, c在各a分组内有序，但跨组无序，仍需Using filesort -
WHERE a = 1 AND b = 2 ORDER BY c✅ 同样有效 -
GROUP BY b, c同理，也要求a是等值条件才能利用索引分组
什么时候该拆索引，而不是硬调查询
强行让所有查询都适配一个联合索引，往往导致索引冗余、写放大、维护成本上升。关键看查询频次、数据分布和更新压力。
性能影响：单表多个联合索引会增加 INSERT/UPDATE/DELETE 的回写开销，尤其当索引列多、数据量大时，延迟明显可测。
- 高频点查（如
WHERE status）+ 低频范围查（如WHERE user_id AND created_at）→ 拆成两个单列或双列索引更合理 - 如果
WHERE a AND c查询占比超过 15%，且b很少参与过滤，那原索引(a, b, c)就是错的，应改为(a, c, b)或新增(a, c) - 注意
SELECT *+ 联合索引覆盖不足时，回表成本可能比全表扫描还高；用EXPLAIN FORMAT=TREE查看是否出现Using index condition或频繁回表
最易被忽略的一点：索引列顺序不仅影响 WHERE，还绑定着 ORDER BY、GROUP BY、JOIN ON 的能力。调查询只是临时止痛，定索引才是根治——但得先看清哪些查询真值得索引服务，哪些该交给应用层分页或缓存扛。
