联合索引需最左前缀匹配：idx_user_status_time仅当WHERE从左连续包含user_id、status、create_time时生效；user_id单独可用，跳过status则create_time失效，无user_id则全表扫描；等值字段应前置，范围字段靠后。
联合索引不是“只要字段在 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+ 树的有序性限制：树只能从根往下按固定路径找，没法跳着走。理解这点，就不会纠结“为什么换个顺序就不行”，也不会幻想优化器能绕过结构硬伤。
