mysql 日志分析工具有哪些_mysql常用分析库

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 本身问题——单看日志，永远看不到上下文。