EXPLAIN 是 MySQL 优化最直接有效的手段，通过分析 type、key、rows、Extra 等关键列可快速定位慢查询根因，如全表扫描、索引失效、文件排序等，并结合 FORMAT=TREE 和 slow log 实战验证优化效果。
用 EXPLAIN 分析 SQL 执行计划，是 MySQL 优化最直接、最有效的手段。它不改代码也能快速定位慢查询根因——比如是否走了索引、有没有全表扫描、连接顺序是否合理、临时表或文件排序是否出现。
看懂 EXPLAIN 输出的关键列
执行 EXPLAIN SELECT ... 后，重点关注以下几列：
- type：访问类型，从好到差通常是 const → eq_ref → ref → range → index → ALL；出现 ALL（全表扫描）要警惕，优先检查 WHERE 条件字段是否有合适索引
- key：实际使用的索引名；为 NULL 表示没走索引，需确认索引是否存在、是否被隐式转换（如字符串字段用数字查询）、是否用了函数/表达式导致失效
- rows：MySQL 预估需要扫描的行数；数值远大于结果集行数，说明过滤效率低，可能缺索引或索引选择性差
- Extra：常见危险信号包括 Using filesort（需优化 ORDER BY）、Using temporary（GROUP BY 或 DISTINCT 涉及非索引字段）、Using join buffer（关联字段无索引）
用 EXPLAIN 发现典型索引问题
很多慢查询其实源于“索引没生效”或“索引建错了”。通过 EXPLAIN 可快速验证：
- 复合索引字段顺序不匹配：比如有索引 (a, b, c)，但查询条件是 WHERE b = ? AND c = ?，EXPLAIN 中 key 会显示 NULL —— 因为没用上最左前缀
- 隐式类型转换：user_id 是 VARCHAR，却写成 WHERE user_id = 123，MySQL 自动转成数字比较，导致索引失效；EXPLAIN 的 key 和 type 会暴露这个问题
- SELECT * 拖累覆盖索引：如果已有索引 (status, create_time)，但语句是 SELECT * FROM t WHERE status = 1 ORDER BY create_time，EXPLAIN 的 Extra 可能出现 Using filesort；改成只查需要字段，或扩展索引为 (status, create_time, id, name) 就可能触发覆盖索引
结合 FORMAT=TREE 看更清晰的执行逻辑
MySQL 8.0+ 支持 EXPLAIN FORMAT=TREE，以树形结构展示各步骤的成本和访问方式，比传统表格更直观：
- 能直接看到哪个 JOIN 表被驱动、哪个是被驱动，以及是否使用了物化（materialized）优化
- 每层节点标注了 cost（预估开销），方便对比不同写法的成本差异
- 例如把子查询改写为 JOIN 后，用 FORMAT=TREE 对比，可明确看到物化步骤消失、成本下降，这就是优化生效的证据
实战中配合 slow log + EXPLAIN 定位真瓶颈
单独看 EXPLAIN 不够，要结合真实执行环境：
- 先开启慢查询日志：SET GLOBAL slow_query_log = ON;，设置 long_query_time = 1，抓出真实慢 SQL
- 对慢 SQL 做 EXPLAIN，再用 EXPLAIN ANALYZE（MySQL 8.0.18+）查看实际执行过程与预估的偏差（比如预估 100 行，实际扫描 10 万行，说明统计信息过期，需 ANALYZE TABLE）
- 注意区分“执行快但调用频繁”和“单次极慢”：前者看 QPS 和总耗时，后者重点看 rows 和 Extra；EXPLAIN 是起点，不是终点
