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) 在线结果，而不是任何离线报告里的“建议”。
