mysql 8.0 慢查询日志本身不记录执行计划（如explain的type、key、extra等），仅记录sql文本、query_time、rows_examined等运行时指标；所谓“更多细节”实为pt-query-digest加--explain、table输出格式或手动执行explain format=json等外部行为所致。
MySQL 8.0 并没有主动“增加”慢查询日志中的执行计划细节——slow_query_log 本身从不记录执行计划（EXPLAIN 输出），它只记录 SQL 文本、执行时间、扫描行数、锁等待时间等运行时指标。你看到的“更多细节”，其实是日志格式或配套工具行为变化带来的错觉，不是日志内容本身升级了。
slow_query_log 文件里到底记了什么？
慢查询日志（slow_query_log_file）始终只写入固定字段，例如：
# Time: 2026-06-15T05:40:22.123456 # User@Host: app[app] @ localhost [127.0.0.1] # Query_time: 2.345678 Lock_time: 0.000123 Rows_sent: 10 Rows_examined: 98765 SET timestamp=1749966022; SELECT * FROM orders WHERE status = 'pending' AND created_at > '2026-06-01';
注意：Rows_examined 是关键线索，但它只是估算值（来自优化器统计），不是真实执行路径；EXPLAIN 的 type、key、Extra 等字段**永远不会出现在慢日志里**。
为什么你觉得“多了执行计划细节”？
真正带来“细节感”的是以下三类外部行为，容易被误认为是慢日志自身增强：
- 你用了
pt-query-digest：这个工具会自动对慢日志里的每条 SQL 执行EXPLAIN（需配置--explain），并把结果附在报告里——但这是工具行为，不是 MySQL 写进去的 - 你开启了
log_output = 'TABLE'并查mysql.slow_log表：该表字段比文件日志多（如sql_text存完整语句），但依然不含执行计划；有人误把sql_text长度变长当成“细节增多” - 你手动把慢 SQL 拿去跑
EXPLAIN FORMAT=TREE：MySQL 8.0 新增了FORMAT=TREE输出，结构更清晰，但这和慢日志无关，纯属你事后分析动作
真正影响执行计划可见性的，是 performance_schema + sys schema
如果你在慢查询发生后想追溯执行计划，正确路径是：
- 查
performance_schema.events_statements_history_long（需提前开启相关 consumers）获取最近执行的 SQL 及其EXPLAIN元数据 - 用
sys.statement_analysis视图看聚合后的avg_latency、full_scan（是否全表扫描）、exec_count—— 这些字段间接反映执行效率，但仍是统计值，不是计划树 - 对具体慢 SQL 手动执行
EXPLAIN FORMAT=JSON：这才是唯一能拿到完整执行计划的方式，且 JSON 格式在 8.0 中更稳定、字段更全（如used_columns、condition_filtering_pct）
别指望慢日志吐出执行计划。它只是个“报警器”，不是“诊断仪”。要看到 type 是 ALL 还是 ref，必须亲手跑 EXPLAIN；要确认索引是否被用上，得看 key 和 possible_keys 字段——这些永远不在慢日志里，也永远不会自动塞进去。
