pt-query-digest 是生产环境首选慢日志分析工具，因其支持指纹抽象、多源日志解析、时间窗口聚合与异常检测，能精准归因性能问题，而 mysqldumpslow 和 mysqlsla 分别受限于功能简陋和长期未更新。
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 本身问题——单看日志，永远看不到上下文。
