不能直接对慢查询日志里的SQL执行EXPLAIN，必须人工提取、清洗、补全后才能准确分析；否则因参数脱敏、语句截断、上下文缺失等原因，执行计划与真实慢SQL严重偏离。
直接说结论：不能对慢查询日志里的 SQL 直接“回放式”用 EXPLAIN，必须人工提取、清洗、补全后才能分析；否则看到的执行计划可能和真实慢 SQL 完全不一致。
为什么慢查询日志里的 SQL 不能直接 EXPLAIN
慢查询日志记录的是实际执行过的语句，但往往包含以下干扰项：
- 参数被脱敏或替换为占位符（如 MySQL 8.0+ 默认将
?<code> 或 <code>: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 ）再 <code>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 配置一起看。
