pt-query-digest解析不出慢查询的根本原因是日志格式不匹配：默认仅支持含“# time:”等注释头的官方原生日志格式，而log_output=table或percona json格式日志无法直接识别；需确认log_output为file并确保日志时间戳准确、格式规范。
pt-query-digest 为什么解析不出慢查询？
常见现象是执行 pt-query-digest /var/lib/mysql/slow.log 后输出只有汇总统计、零条“Query”记录，或提示 0 queries processed。根本原因通常是 MySQL 慢日志格式不匹配：pt-query-digest 默认只识别官方原生日志格式（含 # Time:、# User@Host: 等注释头），而很多线上环境启用了 log_output = TABLE 或使用了 Percona Server 的 JSON 格式慢日志，这类日志无法直接解析。
- 确认日志格式：
SELECT @@log_output, @@slow_query_log_file, @@long_query_time; - 若
log_output = 'TABLE'，需先导出为文件：SELECT * FROM mysql.slow_log INTO OUTFILE '/tmp/slow_raw.txt';（注意：该语句输出的是 CSV，不是 pt-query-digest 所需格式，不推荐） - 更可靠做法是临时切回文件输出：
SET GLOBAL log_output = 'FILE'; SET GLOBAL slow_query_log = OFF; SET GLOBAL slow_query_log = ON;，再等几分钟让新日志生成
如何让 pt-query-digest 正确识别自定义 slow_log 表或 JSON 日志？
Percona Server 支持 log_slow_verbosity = 'full,query_plan,innodb'，会输出带执行计划和锁信息的 JSON 格式慢日志，但 pt-query-digest 默认不支持 JSON 解析。
- 使用
--plugin加载自定义解析器（需 Perl 脚本），但维护成本高，不建议生产用 - 更稳妥的做法是关闭 JSON，改用标准格式并开启额外信息：
SET GLOBAL log_slow_verbosity = 'standard'; SET GLOBAL log_queries_not_using_indexes = ON; - 若必须处理已有的 JSON 慢日志，先用 Python 脚本转换格式（提取
query、time、lock_time等字段，按# Time: 2024-01-01T12:00:00+SELECT ...拼成兼容格式），再喂给pt-query-digest
分析时哪些参数真正影响结果精度？
--since 和 --until 是最常被忽略却最关键的过滤开关。未加限制时，pt-query-digest 会扫描整个文件，一旦日志里有时间错乱（如系统时间回拨、日志轮转不干净），会导致时间窗口错位，top query 排序失真。
- 必须指定合理时间范围：
pt-query-digest --since '2024-04-01 09:00:00' --until '2024-04-01 10:00:00' /var/lib/mysql/slow.log - 配合
--filter可剔除干扰项，例如跳过监控探针 SQL：--filter '$event->{db} && $event->{db} ne "monitor_db" && $event->{fingerprint} !~ m/^select now|sysdate/i' -
--limit控制输出条数（默认 10），但不影响内部聚合逻辑；真正影响聚合粒度的是--group-by，默认按fingerprint分组，若想看每个user+db维度表现，得显式写--group-by fingerprint,user,db
为什么 top query 显示的 Query_time 和实际 EXPLAIN 不符？
pt-query-digest 输出的 Query_time 是日志中记录的总耗时（含网络传输、锁等待、磁盘 IO 等），而 EXPLAIN 只反映优化器预估的执行计划开销，二者不在同一维度。
- 日志中的
Query_time、Lock_time、Rows_sent、Rows_examined才是真实可观测指标 - 若发现某 query 的
Rows_examined远大于Rows_sent，基本可判定缺少有效索引或存在全表扫描 - 注意
pt-query-digest对 prepared statement 的 fingerprint 会做归一化（如SELECT * FROM t WHERE id = ?），但若应用层用了动态拼接列名或表名，fingerprint 会失效，导致相同逻辑的查询被拆成多行——这时要配合--no-report+--print看原始事件，人工比对
真正卡点往往不在工具调用，而在日志源头是否干净、时间戳是否可信、以及 fingerprint 是否能收敛真实业务语义。别急着跑报告，先用 head -20 瞅一眼慢日志前几行长什么样。
