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<br>ORDER BY avg_timer_wait DESC LIMIT 10;对可疑 SQL 直接加 EXPLAIN，再结合
SHOW PROFILE或
sys.schema_table_statistics辅助验证
