mysql如何查看慢SQL的执行计划_利用Explain语句深度拆解-mysql教程-PHP中文网

不能直接对慢查询日志里的SQL执行EXPLAIN，必须人工提取、清洗、补全后才能准确分析；否则因参数脱敏、语句截断、上下文缺失等原因，执行计划与真实慢SQL严重偏离。

mysql如何查看慢sql的执行计划_利用explain语句深度拆解

直接说结论：不能对慢查询日志里的 SQL 直接“回放式”用 EXPLAIN，必须人工提取、清洗、补全后才能分析；否则看到的执行计划可能和真实慢 SQL 完全不一致。

为什么慢查询日志里的 SQL 不能直接 `EXPLAIN`

慢查询日志记录的是实际执行过的语句，但往往包含以下干扰项：

参数被脱敏或替换为占位符（如 MySQL 8.0+ 默认将 ? 或 :id 写成 ?，EXPLAIN 无法推断类型和选择性）
缺少 USE INDEX / FORCE INDEX 等提示，而原 SQL 可能依赖这些强制走索引
语句被截断（尤其长 IN 列表或 JSON 字段操作），EXPLAIN 解析失败或误判
涉及临时表、派生表或 CTE 的语句，在日志中可能丢失上下文（如 WITH t AS (...) SELECT * FROM t 被记为 SELECT * FROM t，但 t 并不存在）

从慢日志提取可 `EXPLAIN` 的 SQL 的实操步骤

以典型慢日志片段为例：

# Time: 2026-04-11T09:23:45.123456Z
# User@Host: app[app] @ 10.20.30.40 [10.20.30.40]  Id: 123456
# Query_time: 3.214876  Lock_time: 0.000123 Rows_sent: 1  Rows_examined: 124890
SET timestamp=1744363425;
SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = ? AND o.created_at > ? ORDER BY o.created_at DESC LIMIT 20;

你需要做的是：

复制完整语句（含 JOIN 和 WHERE），不要删掉注释行或 SET timestamp
把 ? 替换为真实值类型示例：u.status = 'active'、o.created_at > '2026-04-01'（注意用单引号包裹字符串/日期）
确认表别名是否在当前库存在（比如日志里是 users u，但线上分库后可能是 shard_01.users u，需补全库名）
如果语句含函数（如 DATE(o.created_at)），先检查该列是否有函数索引；没有就改写为范围条件（o.created_at >= '2026-04-01' AND o.created_at ）再 EXPLAIN

`EXPLAIN FORMAT=TREE` 比传统格式更准，但有版本限制

MySQL 8.0.16+ 支持树状执行计划，能清晰看出连接顺序、物化子查询、排序是否使用索引等关键信息：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

EXPLAIN FORMAT=TREE SELECT u.name, o.total 
FROM users u 
JOIN orders o ON u.id = o.user_id 
WHERE u.status = 'active' AND o.created_at > '2026-04-01' 
ORDER BY o.created_at DESC LIMIT 20;

重点看输出中的：

-> Limit: 20 row(s) —— 是否在最外层应用 LIMIT，还是先扫描全表再裁剪
-> Sort: o.created_at DESC —— 如果后面跟着 Using filesort，说明 ORDER BY 没走索引
-> Index lookup on o using idx_created_user (created_at > '2026-04-01') —— 真实命中了哪个索引、用了哪些字段
若出现 -> Materialize with deduplication，说明子查询被物化且去重，可能触发磁盘临时表

注意：FORMAT=TREE 不支持 EXPLAIN ANALYZE（后者会真实执行），但比传统表格多一层逻辑结构还原能力。

容易被忽略的三个细节

EXPLAIN 结果里 rows 是预估值，不是真实扫描行数；filtered 是条件过滤后剩余比例，两者相乘（rows * filtered / 100）才接近实际参与连接的行数。很多人只盯 rows，却忽略 filtered 低到 1% 时，哪怕 rows=10000，真正参与连接的只有约 100 行——这时候优化方向应是提升过滤效率，而不是换索引。

另外，key_len 显示的是实际使用的索引字节数，不是定义长度；联合索引 (a,b,c) 中，若只用到 a 和 b，key_len 就不会包含 c 的长度。最后，Extra 里出现 Using temporary 通常意味着排序或分组用了内存/磁盘临时表，但 MySQL 8.0.23+ 对小结果集会自动降级为哈希聚合，不一定代表性能差——得结合 rows 和服务器 tmp_table_size 配置一起看。