联合索引不是“只要字段在 where 里就走索引”
很多人以为只要查询中用了联合索引里的字段，MySQL 就会用上索引——这是最常见的误解。实际上，
idx_user_status_time（
user_id,
status,
create_time）这个索引，只有当
WHERE条件**从左开始连续包含字段**时，才会真正生效。
WHERE user_id = 1001→ 走索引（仅用到
user_id）
WHERE user_id = 1001 AND status = 1→ 走索引（用到
user_id, status）
WHERE user_id = 1001 AND create_time > '2024-01-01'→ 只走
user_id，
create_time不走索引（
status被跳过，后续中断）
WHERE status = 1或
WHERE create_time > '2024-01-01'→ 全表扫描，索引完全失效
注意：MySQL 优化器会自动重排
WHERE子句顺序（比如
status = 1 AND user_id = 1001也会走索引），但前提是**最左列必须出现**——顺序不重要，存在才关键。
范围查询（>、
一旦联合索引中某列用了范围条件，它右边的所有列就无法再参与索引查找了，哪怕你写了等值条件也没用。
WHERE user_id = 1001 AND status = 1 AND create_time > '2024-01-01'→ 索引只用到
status，
create_time是范围起点，之后无延伸
WHERE user_id = 1001 AND status >= 1 AND create_time = '2024-01-02'→
status >= 1是范围，
create_time依然不走索引 反过来，如果把高选择性字段放最左，范围字段放最右（如
(user_id, status, create_time)），就能兼顾等值过滤和时间范围裁剪
所以建联合索引时，优先把等值查询字段放前面，范围字段尽量靠后；
>=和
在某些版本中可能比 <code>>/
多走一位，但别依赖——行为不统一，应以 <code>EXPLAIN的
key_len为准。
explain key_len 是判断索引“走到哪了”的唯一依据
key_len值告诉你 MySQL 实际用了联合索引的前几列，不是“有没有用”，而是“用到了哪一截”。它比看
type或
rows更直接反映最左前缀匹配程度。 假设
user_id是 INT（4 字节），
status是 TINYINT（1 字节），
create_time是 DATETIME（8 字节）
key_len = 4→ 只用了
user_id
key_len = 5→ 用了
user_id + status
key_len = 13→ 三列全用（含 NULL 标志位等细节，实际需查字符集和是否允许 NULL）
别只盯着
key列显示索引名就认为“走对了”——
key_len才是真相。线上慢查排查时，第一眼先看它。
覆盖索引能省掉回表，但得让 select 字段也“守规矩”
联合索引不仅能加速 WHERE，还能当“数据仓库”用——如果
SELECT的字段全在索引里，MySQL 就不用回主键 B+ 树捞数据，这叫覆盖索引。但它同样受最左前缀约束。
CREATE INDEX idx_u_s ON orders(user_id, status, create_time)
SELECT user_id, status FROM orders WHERE user_id = 1001→ 覆盖索引生效 ✅
SELECT status, create_time FROM orders WHERE user_id = 1001→ 不行 ❌，
status和
create_time不构成最左前缀（缺
user_id就不能定位索引块）
SELECT * FROM orders WHERE user_id = 1001→ 索引有效，但要回表查其他字段，性能打折扣
所以设计联合索引时，除了 WHERE 条件，还得顺手把高频
SELECT字段带上——但别乱加，每多一列都增加索引体积和写开销。
最左前缀原则本质是 B+ 树的有序性限制：树只能从根往下按固定路径找，没法跳着走。理解这点，就不会纠结“为什么换个顺序就不行”，也不会幻想优化器能绕过结构硬伤。
