升级MySQL后如何利用工具对比新旧版本的慢查询日志？-mysql教程-PHP中文网

pt-query-digest不能直接对比两个日志，需分别解析后导出csv/json再用脚本比对query_time中位数、rows_examined p95等指标，且版本必须≥3.5.0以正确解析8.0微秒级时间戳。

升级mysql后如何利用工具对比新旧版本的慢查询日志？

pt-query-digest 能否直接对比两个日志？

不能直接“对比”，但能分别解析后导出结构化数据再比对。它本身不提供 diff 模式，但输出 CSV 或 JSON 后可用 shell 或脚本做字段级比对（比如 Query_time 中位数、Rows_examined P95、执行次数）。

常见错误现象：直接运行 pt-query-digest --compare 报错或无输出——这个参数根本不存在。

正确做法是分两次运行，加 --output=profile 或 --report-format=json 提取关键指标
必须确保 Percona Toolkit 版本 ≥ 3.5.0：老版本（如 3.2.x）会把 MySQL 8.0 的微秒级 Query_time: 123456 当作 0 处理，导致延迟统计全崩
若日志路径含空格或特殊字符，务必用引号包裹：pt-query-digest "/var/log/mysql/8.0-slow.log"

mysqldumpslow 为什么在 8.0 日志上失效？

因为它硬编码了 5.7 日志格式，遇到 MySQL 8.0 新增的 # Rows_examined、# Lock_time 等行就跳过整条记录，甚至提前终止解析。

验证是否踩坑：运行 head -n 20 /path/to/slow.log | grep -E '^(# Rows_examined|# Lock_time)'。如果有输出，说明日志带 extra 字段，而你手头的 mysqldumpslow 极大概率来自旧包。

别去改配置关掉 log_slow_extra 来“兼容”——这等于主动丢掉 Rows_examined 和锁等待时间，失去根因判断依据
MySQL 8.0.22+ 自带的 mysqldumpslow 才支持 extra 字段，但功能仍远弱于 pt-query-digest
如果只能用 mysqldumpslow，先用 sed 过滤掉 extra 行：sed '/^# [A-Za-z]/d' slow.log | mysqldumpslow -s t -t 10，但注意这会让 Lock_time 归零，误导性很强

如何提取真正可比的慢查询样本？

直接比“升级前 7 天共 1200 行 vs 升级后 7 天共 800 行”毫无意义——流量波动、缓存状态、业务发布节奏全不同。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

关键不是总量，而是同一业务上下文下的代表性语句。例如订单归档任务每天凌晨 02:00 触发，SQL 模板固定，且应用层打上了 trace_id 标签。

优先从 mysql.slow_log 表中用 user_host 和注释字段过滤，而非只看文件时间戳
禁用 log_queries_not_using_indexes：否则升级后索引优化导致“未走索引”查询减少，会污染慢查基数
用 pt-query-digest --filter '$event->{db} && $event->{db} eq "order_db"' 限定数据库，避免跨库噪声干扰
同一 SQL 模板下，重点比 Query_time 的 P95（不是平均值），因为长尾延迟恶化最易被均值掩盖

为什么 Performance Schema 数据比 slow.log 更可靠？

Query_time 只算语句执行耗时，不含连接建立、网络传输、客户端解析等环节；而升级后 max_connections 或 SSL 握手策略一变，端到端延迟可能飙升，但 slow.log 完全看不到。

真正要盯的是 performance_schema.events_statements_summary_by_digest 里的 AVG_TIMER_WAIT（单位皮秒，需除以 1e12）和 EXECUTIONS，再关联 events_waits_summary_global_by_event_name 看 IO 或锁等待是否异常。

必须手动开启：默认 performance_schema = OFF，查 SELECT @@performance_schema 返回 0 就得立刻开
光开 performance_schema 不够，还要启用消费者：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_statements_%' OR NAME LIKE 'events_waits_%';
别只看 top 10 digest，wait/io/file/innodb/innodb_data_file 等等待事件飙升，往往意味着底层 IO 路径或缓冲池争用模型变了

真正容易被忽略的是：MySQL 8.0 默认只记录已提交事务的慢语句，而 5.7 会记未提交的。如果你的业务有长事务，这部分日志在升级后就“消失”了——不是性能变好，是统计口径变了。