mysqldumpslow、
pt-query-digest、
mysqlsla是当前最实用的三款 MySQL 慢日志分析工具，其中
pt-query-digest在生产环境里事实成为首选——它解析准、聚合稳、支持多日志源（slow log / tcpdump / processlist），且输出结构清晰，可直接用于性能归因。
为什么 pt-query-digest
值得优先装？
Percona Toolkit 中的
pt-query-digest不是“又一个统计脚本”，而是带指纹抽象、时间窗口聚合、异常检测能力的日志分析引擎。相比
mysqldumpslow（仅排序+去重）和
mysqlsla（报表丰富但 Perl 依赖重、已多年未更新），它在以下场景明显更可靠： 慢日志中含大量
WHERE id = ?类参数化查询时，
pt-query-digest能自动指纹化为同一类，
mysqldumpslow默认不抽象，需加
-a才勉强支持，且效果不稳定 日志跨天滚动（如
slow.log.20251228、
slow.log.20251229），
pt-query-digest可直接通配：
pt-query-digest /var/log/mysql/slow.log.* > report.txt遇到
Lock_time异常高但
Query_time低的语句，它会单独标注 “InnoDB lock wait” 并关联事务信息，而
mysqlsla仅汇总数值，无法定位锁源头
mysqldumpslow
适合什么人用？
MySQL 官方自带、零依赖、开箱即用，适合临时排查或资源受限的边缘节点（如测试机、CI 环境）。但它有硬伤：
不识别日志格式变更：MySQL 8.0 后默认启用log_output = TABLE时，日志写入
mysql.slow_log表，
mysqldumpslow完全无法读取，必须先导出为文件：
SELECT * FROM mysql.slow_log INTO OUTFILE '/tmp/slow.log';
-s r（按返回行数排序）实际统计的是
Rows_sent，但很多慢查卡在扫描（
Rows_examined高），这个指标毫无意义 不支持过滤用户/IP/数据库：想看
app_user@10.20.30.%的慢查？只能靠
grep预处理，再喂给
mysqldumpslow
mysqlsla
还值得折腾吗？
功能上确实曾比
mysqldumpslow全面，但现实很骨感： 源码托管在已归档的
hackmysql.com，GitHub 仓库
daniel-nichter/hackmysql.com自 2017 年起无更新，Perl 依赖（如
Time::HiRes）在较新系统（CentOS Stream / Rocky 9）上易编译失败 输出含
95% of Time等统计，听起来专业，但该值基于简单截尾均值，对长尾毛刺不敏感；而
pt-query-digest默认提供
median和
P95，并标记离群点 不支持二进制日志或 general log 分析，纯 slow log 工具，在需要交叉验证（如“这条慢查是否伴随大量临时表？”）时立刻掉链子
真正容易被忽略的点是：日志分析不是独立动作，必须和监控联动。比如
pt-query-digest输出里某类查询
P95 Query_time突增 300%，若此时 Prometheus 中
mysql_global_status_threads_running也同步飙升，基本可断定是锁争用而非 SQL 本身问题——单看日志，永远看不到上下文。
