SQL 慢查询捕获工具 pt-query-digest / pgBadger / everSQL 的报告解读模板

pt-query-digest 默认按总query_time排序，但需重点关注count、query_time、rows_examined三列；rows_examined远大于rows_sent通常表明索引失效。

怎么看 pt-query-digest 输出里最耗时的那几条 sql

pt-query-digest 默认按 Query_time 总和排序，但真正卡住业务的往往不是单次最慢的语句，而是高频+中等延迟的“温吞水”查询。重点看三列：Count（执行次数）、Query_time（总耗时）、Rows_examined（扫描行数）——如果 Rows_examined 远大于 Rows_sent，基本就是没走索引或索引失效。

实操建议：

• 用 pt-query-digest --Filter '$Event->{Rows_examined} > 1000 && $event->{Rows_sent} 快速筛出“查得多、返回少”的语句
• 注意 px 字段：值为 1 表示该语句被并行执行过，可能掩盖单次真实延迟
• EXPLAIN 前先加 /*+ MAX_EXECUTION_TIME(1000) */ 防止长跑阻塞分析

pgBadger 报告里 “Top Queries by Duration” 和 “by Calls” 差异太大怎么判断优先级

postgresql 的慢日志粒度比 mysql 细，Duration 是从解析到返回的全链路时间，含锁等待、WAL 写入、Buffer I/O 等；而 Calls 只是调用次数。当两者排序差异大，说明系统存在明显资源争用点。

实操建议：

• 优先处理同时出现在两个 Top10 里的语句——这类语句既频繁又拖累整体响应
• 如果某语句在 by Duration 排前 5 但 by Calls 很靠后，检查 pg_stat_activity 中对应 wait_event_type 是否为 Lock 或 IO
• pgBadger 生成时加 --enable-queries 才能展开具体 SQL 文本，否则只显示哈希摘要

everSQL 建议的“添加复合索引”为什么线上加了反而更慢

everSQL 基于单条 SQL 的 EXPLAIN 结果做静态推演，不考虑数据分布倾斜、统计信息陈旧、并发更新冲突等运行时因素。尤其当表有大量 UPDATE 或 delete 时，新索引会显著拖慢写入，并可能让优化器误选执行计划。

实操建议：

• 上线前必须在相同数据量的备库上跑 EXPLAIN (ANALYZE, BUFFERS) 对比原计划与新索引下的实际执行路径
• 避免在 WHERE 条件含 OR、函数表达式、或类型隐式转换的字段上建索引——everSQL 不校验这些
• 用 pg_stat_all_indexes 查 idx_scan 和 idx_tup_read，确认索引是否真被命中；若 idx_scan = 0，说明优化器根本没选它

三个工具报告里都出现 “no index used” 却找不到缺失索引怎么办

不是所有“没走索引”的场景都能靠加索引解决。常见真实原因是：查询条件含 IS NULL、LIKE '%xxx'、列上有函数（如 UPPER(name)），或者统计信息严重不准导致优化器误判。

实操建议：

• 对 WHERE 子句逐个注释掉条件，用 EXPLAIN 观察执行计划变化，定位“破坏索引选择”的那个条件
• 执行 ANALYZE table_name 更新统计信息，再对比计划；若仍不走索引，说明该条件本身无法利用 B-tree 索引
• pgBadger 报告中点击具体 SQL 的 Query ID 可跳转原始日志行，检查当时 application_name 和 client_addr，常能发现 ORM 自动生成的低效语句

慢查询报告只是线索，不是诊断结论。同一份日志，pt-query-digest 关注执行时间分布，pgBadger 强调会话上下文，everSQL 专注单语句改写——它们互相矛盾时，优先信 EXPLAIN (ANALYZE, BUFFERS) 在线结果，而不是任何离线报告里的“建议”。