EXPLAIN核心是盯住type、key、rows、Extra四字段：type判断访问效率（ALL/index需警惕），key/key_len确认索引使用情况，rows反映扫描行数，Extra揭示隐式开销（如filesort、temporary）。
看 EXPLAIN 输出，核心是快速定位性能瓶颈，不是逐字翻译每一列。重点盯住 type、key、rows、Extra 这四个字段，它们直接反映查询是否走索引、扫描范围多大、有没有额外开销。
先看 type：访问类型决定效率上限
这个字段排在性能优劣序列里，从好到差大致是：
system → const → eq_ref → ref → range → index → ALL
重点关注是不是掉到了 index（全索引扫描）或更差的 ALL（全表扫描）。这两种意味着没用好索引，或者根本没索引可用。
- eq_ref：通常是主键或唯一索引 JOIN，效率高，说明连接条件精准
- ref：用了非唯一索引，比如普通字段上的索引，还算合理
- range：走了索引范围查找（如 WHERE id BETWEEN 10 AND 20），比全扫好，但不如等值查
- ALL：危险信号，尤其在大表上，要立刻检查 WHERE 条件是否有对应索引
再核 key 和 key_len：索引到底用没用上
key 显示实际生效的索引名；如果为 NULL，说明优化器没选任何索引——哪怕 possible_keys 里有候选项，也要怀疑索引设计或条件写法有问题。
key_len 表示用了索引的多少字节，能帮你判断是否用了联合索引的最左前缀。例如索引是 (a,b,c)，key_len 只显示 a 字段长度，说明只用到了第一列；如果显示 a+b 的长度，说明用到了前两列。
- key 为空但表有索引？检查 WHERE 条件是否符合最左前缀原则
- key_len 比预期小？可能是隐式类型转换（如字符串字段传数字）导致索引截断
- key_len 显示最大可能长度？说明该字段允许 NULL 或是变长类型（如 VARCHAR）
关注 rows：预估扫描行数越少越好
这个值是优化器估算的“需要读取多少行才能找到结果”，不是返回行数。它和实际性能强相关：rows 越大，I/O 和 CPU 开销越高。
注意它只是估算，受统计信息影响。如果发现 rows 偏离实际太多（比如查 1 条却报 10 万），可运行 ANALYZE TABLE 表名 更新统计信息。
- rows 接近表总行数？大概率是全表/全索引扫描，需优化
- JOIN 多张表时，各表 rows 相乘接近最终执行代价，要优先优化 rows 最大的那张表
- 加了 LIMIT 不一定减少 rows 值——优化器可能仍按无 LIMIT 估算
别漏掉 Extra：隐藏问题常在这里暴露
这是诊断细节的关键字段，常见提示含义明确：
- Using index：好消息，覆盖索引，不用回表
- Using where：WHERE 条件在存储引擎层后做过滤（正常）
- Using filesort：需要额外排序，没走索引排序，ORDER BY 字段没索引或不匹配
- Using temporary：用了临时表，常见于 GROUP BY、DISTINCT、某些 JOIN 场景，尽量避免
- Using join buffer：关联字段没索引，改用块嵌套循环，性能较差
- Impossible WHERE：条件恒假，直接返回空，也可能是逻辑写错了
