EXPLAIN 是 MySQL 查看 SQL 执行计划的核心命令，用于识别慢查询瓶颈，重点关注 id、select_type、type、possible_keys、key、key_len、rows 和 Extra 等列，并可通过 FORMAT=JSON、ANALYZE 或 ANALYZE TABLE 提升分析准确性。
EXPLAIN 是 MySQL 中查看 SQL 执行计划的核心命令，它能帮你快速识别慢查询的瓶颈所在，比如是否走了索引、是否发生全表扫描、是否用到临时表或文件排序等。
怎么看 EXPLAIN 输出的关键列
执行 EXPLAIN SELECT ... 后，重点关注以下几列：
- id：查询编号，相同 id 表示同一执行层级；数字越大越先执行（若含子查询或 UNION）
- select_type：查询类型，如 SIMPLE（简单查询）、PRIMARY（最外层）、SUBQUERY（子查询）、DERIVED（派生表）等，复杂类型往往意味着额外开销
-
type：连接类型，性能从优到劣大致为：
system ≈ const > eq_ref > ref > range > index > ALL。出现ALL就是全表扫描，需重点优化 -
possible_keys 和 key：前者列出可能用上的索引，后者是实际选中的索引。如果
key为NULL，说明没走索引 -
key_len：实际使用索引的字节数，可据此判断是否用了联合索引的最左前缀（例如索引是
(a,b,c)，key_len显示只用了前两个字段，说明WHERE a=? AND b=?有效，但c未参与过滤） - rows：MySQL 预估需要扫描的行数，数值越大越危险；注意这只是估算，不一定等于实际扫描量
-
Extra：重要补充信息，常见值有：
•Using where：用 WHERE 条件过滤结果（正常）
•Using index：覆盖索引，无需回表（高效）
•Using filesort：需要额外排序（尽量避免，考虑加索引优化 ORDER BY）
•Using temporary：用到了临时表（常见于 GROUP BY、DISTINCT 或某些 JOIN 场景，较重）
如何让 EXPLAIN 更贴近真实执行情况
默认 EXPLAIN 不执行 SQL，仅做预估。想看更准的执行信息，可用以下方式：
- 加
FORMAT=JSON：执行EXPLAIN FORMAT=JSON SELECT ...，返回结构化 JSON，包含成本估算、实际扫描行数（在execution_summary中）、是否使用 MRR 等细节 - 配合
ANALYZE：MySQL 8.0+ 支持EXPLAIN ANALYZE SELECT ...，它会真正执行语句并返回实际耗时、真实扫描行数、各阶段耗时分布，比普通 EXPLAIN 更有参考价值 - 确保统计信息准确：定期运行
ANALYZE TABLE table_name更新表的索引统计信息，避免因过期统计导致执行计划误判
常见低效模式与对应优化方向
通过 EXPLAIN 发现以下现象时，通常意味着可优化：
-
type = ALL且rows很大 → 检查 WHERE 条件字段是否缺少索引，或现有索引未被正确使用（如对索引字段做函数操作：WHERE YEAR(create_time) = 2023） -
Extra出现Using filesort→ 对 ORDER BY 字段建索引，或让排序字段落在联合索引后缀位置（如ORDER BY a, b，索引(a,b)可覆盖） -
Extra出现Using temporary→ 检查 GROUP BY 是否能利用索引有序性；避免在 GROUP BY 或 ORDER BY 中混用 ASC/DESC；简化 SELECT 列，减少 DISTINCT 的使用场景 -
key有值但key_len偏小 → 联合索引未充分利用，调整 WHERE 条件顺序或重建更匹配的索引
小技巧：快速定位问题 SQL
在生产环境排查慢查询时，别只靠肉眼扫日志：
- 开启慢查询日志 +
log_queries_not_using_indexes = ON，自动捕获未走索引的查询 - 用
performance_schema查最近执行的高成本语句：SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY avg_timer_wait DESC LIMIT 10; - 对可疑 SQL 直接加 EXPLAIN，再结合
SHOW PROFILE或sys.schema_table_statistics辅助验证
