explain 是 mysql 查看查询执行计划的工具，不执行语句只展示优化器预估的访问方式、索引使用、连接顺序等；核心字段包括 id、select_type、type、key、rows 和 extra；结合 analyze table、force index 及 format=json 可深度调优，并需关注不同参数下执行计划稳定性。
EXPLAIN 是查看 SQL 查询执行过程的“透视镜”，它不运行查询，只告诉你数据库打算怎么执行——从表扫描方式、连接顺序、索引使用到临时表和排序行为，全都一目了然。
读懂 EXPLAIN 输出的核心字段
以 MySQL 为例，重点关注以下几列：
- id：查询中每个 SELECT 的编号，值越大越先执行（注意：有子查询或 union 时 id 可能为 NULL）；
- select_type：是简单查询（SIMPLE）、子查询（SUBQUERY）、派生表（DERIVED）还是联合查询（UNION）；
- type：访问类型，从好到差大致是 system ≈ const > eq_ref > ref > range > index > ALL；其中 ALL 表示全表扫描，通常是性能瓶颈信号；
- key：实际用到的索引名，为 NULL 说明没走索引；
- rows：MySQL 预估需要扫描的行数，数字越小越好，显著高于实际结果集说明索引失效或统计信息不准；
- Extra：常见警告项如 using filesort（需额外排序）、Using temporary（建临时表）、Using join buffer（非驱动表用缓存连接），都可能拖慢速度。
快速定位常见性能问题
结合 EXPLAIN 结果，对照典型低效模式检查：
- WHERE 条件字段没索引，或用了函数/表达式（如
WHERE YEAR(create_time) = 2023），导致索引失效； - 联合索引未按最左前缀使用（如索引是
(a,b,c)，但查询只用WHERE b = ?）； - JOIN 时关联字段类型不一致（如一个是
VARchar，另一个是CHAR或长度不同），引发隐式转换，跳过索引； - SELECT * 或返回大量字段，尤其在覆盖索引不满足时，会回表多次，可改用所需字段 + 覆盖索引优化；
- ORDER BY 字段不在索引中，或与 WHERE 条件无法共用同一索引，触发
Using filesort。
配合 ANALYZE TABLE 和 FORCE INDEX 辅助判断
EXPLAIN 基于统计信息估算，有时不准：
- 执行
ANALYZE TABLE table_name;更新表的索引统计，让执行计划更贴近真实数据分布； - 对复杂 JOIN 或优化器选错索引的情况，可用
EXPLAIN SELECT ... FORCE INDEX (idx_name) ...强制走某索引，对比 rows 和 Extra 变化； - MySQL 8.0+ 支持
EXPLAIN FORMAT=JSON，提供更详细的代价模型、过滤率、访问路径依赖等，适合深度调优。
不止看单条语句：关注执行计划是否稳定
同一条 SQL 在不同参数下可能生成不同执行计划：
- 用
EXPLAIN SELECT ... WHERE col = 'a'和EXPLAIN SELECT ... WHERE col = 'b'对比，观察 type、rows 是否突变——说明数据倾斜或索引选择不稳定； - 上线前用不同业务参数批量跑 EXPLAIN，避免“看似正常，一上生产就慢”；
- 监控 slow log 中的 SQL，自动提取并定期分析其执行计划变化，及时发现隐性退化。