EXPLAIN 是 SQL 中查看查询执行计划的核心工具，不真正执行语句，用于识别慢查询根源；关键列包括 id、select_type、type、possible_keys、key、key_len、rows 和 Extra，结合 FORMAT=JSON 或 ANALYZE 可提升分析深度。
EXPLAIN 是 SQL 中查看查询执行计划的核心工具，它不真正执行语句，而是告诉数据库“打算怎么执行”，帮你发现慢查询的根源。 掌握它，等于拿到查询性能的透视镜——索引是否命中、是否触发全表扫描、连接顺序是否合理，一目了然。
看懂 EXPLAIN 输出的关键列
以 MySQL 为例，运行 EXPLAIN SELECT … 后返回的表格中，以下几列最需关注：
- id：查询中每个 SELECT 的编号。值相同表示并列执行；值递增表示子查询或 UNION 中的嵌套层级
- select_type：查询类型，如 SIMPLE（简单查询）、PRIMARY（主查询）、SUBQUERY（子查询）、DERIVED（派生表）等，反映语句结构复杂度
- type：访问类型，性能由优到劣常见为：const ≈ eq_ref > ref > range > index > ALL。出现 ALL 意味着全表扫描，通常是性能瓶颈信号
- possible_keys 和 key：前者是可能用上的索引，后者是实际选用的索引。若 key 为 NULL，说明没走索引
- key_len：索引使用长度（字节）。值越小通常越精准；对比联合索引字段顺序，可判断用了前缀几列
- rows：预估需要扫描的行数。该值越大，I/O 和计算开销越高，是调优重点参考指标
- Extra：额外信息，重点关注：Using filesort（需排序但无合适索引）、Using temporary（临时表，常因 GROUP BY 或 DISTINCT 引起）、Using join buffer（非驱动表未走索引）
实战中快速定位常见问题
不要只盯着单条语句的输出，要结合业务逻辑和数据特征交叉判断：
- WHERE 条件字段没索引？→ 在 possible_keys 为空且 type=ALL 时基本可确认，应补索引
- 联合索引没生效？→ 检查 key_len 是否符合预期，再核对 WHERE 中字段是否满足最左前缀原则（例如索引 (a,b,c)，WHERE b=1 AND c=1 不会走索引）
- ORDER BY 慢？→ 若出现 Using filesort，优先考虑在 ORDER BY 字段上建立覆盖索引，或让排序字段与 WHERE 条件共用同一联合索引
- JOIN 效率低？→ 观察各表的 type 和 rows，驱动表（外层表）应尽量小且走高效索引；被驱动表（内层表）必须有匹配的关联字段索引
进阶技巧：让 EXPLAIN 更有用
基础 EXPLAIN 只显示预估计划，真实执行可能不同。可用这些方式增强分析深度：
- 加 FORMAT=JSON：如 EXPLAIN FORMAT=JSON SELECT …，返回结构化 JSON，含成本估算、具体访问方法、索引合并细节等，适合深入诊断
- 配合 ANALYZE：MySQL 8.0+ 支持 EXPLAIN ANALYZE，真正执行语句并返回实际耗时、真实扫描行数，比预估更可信
- 对比前后变化：修改索引或重写 SQL 后，重新运行 EXPLAIN，重点对比 type、rows、Extra 三项是否改善
- 注意查询缓存干扰：MySQL 5.7 及以前默认开启查询缓存，可能导致 EXPLAIN 结果失真；建议在分析前加 SQL_NO_CACHE（如 SELECT SQL_NO_CACHE …）
不同数据库的小差异
虽然核心思想一致，但语法和字段名略有不同：
- PostgreSQL：用 EXPLAIN 或 EXPLAIN (ANALYZE, BUFFERS)，关键列是 Node Type、Rows Removed by Filter、Buffers
- SQL Server：用 SET SHOWPLAN_ALL ON 或图形化执行计划（Ctrl+L），重点关注 Estimated Subtree Cost 和警告图标（如缺失索引提示）
- Oracle：常用 EXPLAIN PLAN FOR + SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)，关注 Operation、Options、Cost
