explain 的 key 和 type 字段是索引使用判断的核心：key 为 null 表示未用索引，type 为 all 或 index 通常意味着索引失效；联合索引需满足最左前缀连续匹配，且 order by 字段必须在索引中并保持有序才能避免 using filesort。
看 EXPLAIN 的 key 和 type 字段
直接执行 EXPLAIN SELECT ...，重点盯住两个字段：key 显示实际用的索引名，type 反映访问效率。如果 key 是 NULL，说明联合索引根本没被选中；如果 key 有值但 type 是 ALL 或 index，大概率是写法触发了失效——比如对索引列用了函数、隐式转换，或条件里跳过了最左列。
WHERE 条件是否满足最左前缀连续匹配
联合索引 (a, b, c) 不是“有 a 或 b 或 c 就能用”，而是必须从左开始连续出现且等值（或 IN）才生效：
-
WHERE a = 1✅ 用上a段 -
WHERE a = 1 AND b = 2✅ 用上a,b段 -
WHERE a = 1 AND b > 10 AND c = 3⚠️c失效（b是范围，断层） -
WHERE b = 2❌ 全表扫描，key为NULL -
WHERE a = 1 AND c = 3⚠️c完全不参与索引查找（b缺失）
注意 ORDER BY 是否触发 Using filesort
即使 WHERE 走了联合索引，排序也可能额外开销。比如索引是 (user_id, create_time)：
-
WHERE user_id = 123 ORDER BY create_time✅ 索引覆盖过滤+排序，Extra无Using filesort -
WHERE user_id > 100 ORDER BY create_time❌user_id是范围，create_time无法保持有序，必出Using filesort -
WHERE user_id = 123 ORDER BY status❌status不在索引中，也必出Using filesort
别信 possible_keys 有值就代表索引生效
possible_keys 只表示优化器“考虑过”这个索引，但最终是否采用，得看 key。常见误导场景：
- 字段类型不一致导致隐式转换（如
varchar索引列查整数） - 条件含
OR且其中一侧无索引 - 模糊查询写成
LIKE '%abc'（左侧通配） - 对索引列使用函数，如
WHERE YEAR(create_time) = 2025
这些都会让 possible_keys 显示索引名，但 key 仍是 NULL —— 最容易被忽略的是类型不匹配和函数包裹，一查 EXPLAIN 就露馅。
