慢查询日志需验证真实性：确认slow_query_log=on、long_query_time合理（建议0.5s–1s）、日志非空且时间戳有效；分析须用绝对时间切片、关注query_time:sum与rows_examined:sum双指标趋势，结合pt-query-digest写入query_history表实现长期追踪。
确认慢查询日志是否真实反映生产负载
pt-query-digest 分析结果是否可信，第一关是日志本身有没有“失真”。生产环境常见陷阱包括：long_query_time 设得过高（比如 10s），导致大量中等耗时（2–5s）的查询被漏掉；或启用了 log_queries_not_using_indexes 但没配 min_examined_row_limit，导致全表扫描语句泛滥、淹没真正高耗时查询。
务必先验证：
- 执行
SHOW GLOBAL VARIABLES LIKE 'slow%';确认slow_query_log = ON且slow_query_log_file路径可读 - 检查
long_query_time是否匹配业务敏感度（建议从 1s 或 0.5s 开始，而非默认 10s） - 用
tail -n 100 /var/lib/mysql/mysql-slow.log | head -20快速扫几条日志时间戳，确认不是日志轮转后空文件或旧归档
用 --since 和 --until 做时间切片对比
单次报告只能看“快照”，要识别趋势必须横向比。比如想验证某次上线后 SQL 性能是否退化，不能只跑一次 pt-query-digest /var/lib/mysql/mysql-slow.log，而要固定时间窗口做差分。
实操要点：
- 用绝对时间比相对时间更稳：
pt-query-digest --since '2026-06-04 00:00:00' --until '2026-06-04 23:59:59' /var/lib/mysql/mysql-slow.log > report_20260604.txt - 避免
--since=24h这类动态参数——它每次执行基准时间不同，跨天对比会错位 - 如果日志已按天轮转（如
mysql-slow.log-20260604），直接指定文件更可靠，省去时间过滤开销
关注 Query_time:sum 和 Rows_examined:sum 的双指标漂移
只盯着“平均响应时间”容易误判。生产中更关键的是两个聚合值的变化趋势：Query_time:sum（该类 SQL 总耗时）和 Rows_examined:sum（总扫描行数）。前者上升可能因并发增加，后者上升往往指向索引失效或查询逻辑变更。
例如同一指纹 SELECT * FROM orders WHERE user_id = ? AND status = ?：
- 若
Query_time:sum↑ 30%，但Rows_examined:sum↑ 200%，大概率是status字段没走索引，或新增了低选择性值导致索引失效 - 若两者同比例上升，更可能是数据量增长或并发请求翻倍，需结合应用层 QPS 日志交叉验证
- 用
--order-by Query_time:sum,Rows_examined:sum排序，能同时暴露耗时和扫描量双高的“坏查询”
把历史报告存进数据库做长期追踪
人工比对文本报告不可持续。pt-query-digest 支持将每次分析结果写入 MySQL 表，实现自动化趋势监控。
关键步骤：
- 先建表：
pt-query-digest --create-review-table --review h=localhost,D=percona,t=query_review - 每次分析写入：
pt-query-digest --review h=localhost,D=percona,t=query_review --history h=localhost,D=percona,t=query_history /var/lib/mysql/mysql-slow.log-20260605 -
query_history表会自动记录checksum、ts_min、Query_time_sum等字段，后续可用 SQL 按指纹查趋势：SELECT ts_min, Query_time_sum, Rows_examined_sum FROM query_history WHERE checksum = ? ORDER BY ts_min;
注意：不要复用同一个 query_review 表长期写入，容易因 fingerprint 变化导致重复插入失败；query_history 才是为趋势设计的，且需定期清理旧数据防止膨胀。
