如何使用 MySQL 的 EXPLAIN 语句进行查询分析？

🏛 业务架构师

EXPLAIN 是我把"慢查询治理"做成研发流程资产的核心工具，重点看五列：

type（访问方式）：从好到坏 system > const > eq_ref > ref > range > index > ALL。业务红线：核心交易查询至少 range，出现 ALL（全表扫描）一律打回；index 是"扫整棵索引树"，也别放过；
key / key_len：是否走了预期索引、用了索引的前几列——key_len 能暴露"联合索引只吃到一半"的问题，说明列顺序与查询不匹配；
rows（预估行数）：优化器的估算。rows 乘以调用频率就是这张表的 IO 预算，我习惯用 rows × QPS 评估容量风险；
Extra（关键信号灯）：Using index 是覆盖索引（好）；Using filesort 是额外排序、Using temporary 是临时表——大流量接口出现这两个，是未来故障的预告，order by/group by 的索引设计要重审；Using index condition 是索引下推生效。

流程上我落成两条规矩：

上线卡点：核心表新增/修改的 SQL 必须附 EXPLAIN 结果，CR 时对照检查——把治理从"事后救火"前移到"事前拦截"，慢查询事故率断崖式下降；
结合 optimizer trace：当优化器" inexplicably 不走索引"时，trace 能看到各候选计划的成本估算，区分是统计信息过旧（analyze table）还是真的全扫更便宜。

一句话：EXPLAIN 单次使用是技巧，嵌入流程变成卡点才是架构动作。

EXPLAIN 是我给 SQL 做"体检"的第一工具，输出里重点看五列：

type（访问方式，性能阶梯）：system > const > eq_ref（join 主键/唯一键）> ref（普通索引等值）> range（索引范围）> index（全索引扫描）> ALL（全表扫描）。生产要求至少 range，出现 ALL 基本要治理；
key / key_len：实际用到的索引及使用长度。key_len 可以反推联合索引用了几列（比如 (a,b) 各 4B，key_len=8 说明两列都用上了）；key 为 NULL 就是没走索引；
rows（预估扫描行数）：优化器估算，和实际可能有偏差，但数量级是可靠的。扫描 10 万返回 10 行，说明过滤性差或回表多；
Extra（关键信号）：
- Using index：覆盖索引，好；
- Using index condition：索引下推生效；
- Using where：Server 层过滤；
- Using filesort / Using temporary：额外排序/临时表，ORDER BY 没吃到索引，大结果集要重点优化；
id 与 select_type：id 相同自上而下执行，不同（子查询）id 大的先执行；DERIVED、DEPENDENT SUBQUERY 都可能是性能陷阱。

我的习惯：可疑 SQL 一律 explain + 真实数据量验证，必要时 explain analyze（8.0）看实际执行耗时分解，不信估算信实测。

EXPLAIN（8.0 可加 ANALYZE 跑真实执行）输出里我固定看五列，按优先级：

type（访问方式）：system > const > eq_ref > ref > range > index > ALL。const/eq_ref（主键或唯一索引）、ref（普通索引等值）是健康状态；range（范围）可接受；index（扫整棵索引树）和 ALL（全表）必须优化。
key + key_len：实际用的索引和长度。key 是 NULL 就是没用上；联合索引 (a,b,c) 中 a int(4)+可空标志、b varchar(32)，key_len 等于几就能推算出用到第几列。
rows：预估扫描行数。我拿它和实际返回行数比，扫 100 万返回 100 行的 SQL 再怎么走索引也该改写。
Extra：
- Using index：覆盖索引，好；
- Using index condition：索引下推；
- Using where：Server 层过滤，通常说明索引没筛干净；
- Using filesort / Using temporary：排序/分组没走索引，数据量大时要处理；
- Using join buffer：被驱动表 join 字段没索引。

实操习惯：优化前先 EXPLAIN FORMAT=TREE 看计划形状（有没有被驱动表全扫），改完 SQL 用 EXPLAIN ANALYZE 对比真实耗时——优化器估算有时骗人，真实执行不会。