要查看 MySQL 慢查询的执行计划，核心方法是使用 EXPLAIN 命令分析 SQL 语句的执行方式。这能帮助你理解查询为何变慢，比如是否走了索引、扫描了多少行数据等。
开启并定位慢查询
在分析之前，先确认哪些查询是“慢查询”：
确保慢查询日志已开启：SHOW VARIABLES LIKE 'slow_query_log';
如果值为 OFF，可通过配置文件或运行时命令开启。 设置慢查询阈值（例如超过2秒）：
SET long_query_time = 2; 查看慢查询日志文件位置：
SHOW VARIABLES LIKE 'slow_query_log_file';
通过日志找到具体的慢 SQL 语句后，就可以进行执行计划分析了。
使用 EXPLAIN 查看执行计划
将慢查询的 SQL 语句前面加上 EXPLAIN 即可查看其执行计划：
EXPLAIN SELECT * FROM users WHERE age > 30;返回结果中的关键列说明：
id：查询的标识符，联合查询时能看出执行顺序 select_type：查询类型，如 SIMPLE、PRIMARY、SUBQUERY 等 table：涉及的表名 type：连接类型，常见有 system/const/ref/range/index/all，越靠前越好 possible_keys：可能使用的索引 key：实际使用的索引 rows：估计需要扫描的行数，越大越慢 Extra：额外信息，如 Using filesort、Using temporary 表示存在性能问题结合 EXPLAIN FORMAT=JSON 获取更详细信息
MySQL 5.6+ 支持 JSON 格式的执行计划，提供更深入的优化建议：
EXPLAIN FORMAT=JSON SELECT * FROM users WHERE age > 30;输出中会包含成本估算、是否使用索引下推（ICP）、物化等高级信息。
启用 Performance Schema 辅助分析
MySQL 的 Performance Schema 可以记录语句执行统计，配合使用效果更好：
开启相关监控：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'statement/%'; 查询最近执行的语句：
SELECT DIGEST_TEXT, AVG_TIMER_WAIT / 1000000000 AS avg_sec FROM performance_schema.events_statements_summary_by_digest ORDER BY avg_timer_wait DESC LIMIT 5;
找到耗时高的语句后，再用 EXPLAIN 分析其执行路径。
基本上就这些。关键是通过慢查询日志发现问题 SQL，然后用 EXPLAIN 看执行计划，重点关注 type、key、rows 和 Extra 字段，快速定位索引缺失或全表扫描等问题。
