开启slow_query_log并配置long_query_time=0.1、log_queries_not_using_indexes=ON等参数，再用pt-query-digest指纹聚合分析，结合EXPLAIN验证，最后固化为监控告警与审核闭环。
直接开启并用好 slow_query_log，再配合 pt-query-digest 做聚合归因和执行路径深挖，就能从海量日志里揪出真正拖垮系统的那几条 SQL。关键不在“全量记录”，而在“精准归类+可回溯验证”。
一、让 slow_query_log 真正捕获问题语句
默认配置往往漏掉隐性慢 SQL。需手动强化捕获能力：
- 设 long_query_time = 0.1（100 毫秒），尤其对高并发 OLTP 场景，1 秒阈值已严重滞后
- 强制记录未走索引的查询：log_queries_not_using_indexes = ON，这类语句常被忽略但危害极大
- 启用管理语句记录：log_slow_admin_statements = ON，ALTER、ANALYZE 等操作卡顿也会拖垮服务
- 加过滤门槛：min_examined_row_limit = 100，避免大量轻量小结果集刷屏日志
- 输出双通道：log_output = 'FILE,TABLE'，既写文件便于离线分析，也存入
mysql.slow_log表支持 SQL 查询比对
二、用 pt-query-digest 把日志“翻译”成优化线索
它不是简单统计，而是通过指纹化（Fingerprint）把 SELECT * FROM order WHERE uid=123 和 uid=456 合并为同一类，再排序归因：
- 基础分析：
pt-query-digest /var/log/mysql/mysql-slow.log > report.txt，报告首屏即显示“总响应时间 Top 10” - 聚焦最近问题：
pt-query-digest --since '12h' slow.log，排除历史噪音，直击当前瓶颈 - 筛出高危模式：
pt-query-digest --filter '$event->{Full_scan} eq "yes"' slow.log，专抓全表扫描语句 - 按用户隔离分析：
pt-query-digest --filter '($event->{user}||"") =~ m/^app/i' slow.log，快速定位某应用模块的问题 - 导出到数据库：
pt-query-digest --review h=localhost,D=audit,t=query_review --create-review-table slow.log，建立可追踪、可对比的历史基线
三、对准重点 SQL 做 EXPLAIN 级别验证
pt-query-digest 给出的是“哪类 SQL 最伤”，EXPLAIN 才能告诉你“为什么伤”：
- 复制报告中“Example query”里的典型语句，在生产从库或测试环境执行
EXPLAIN FORMAT=JSON - 紧盯四个字段：type（是否为
ALL或index）、key（是否用了预期索引）、rows（预估扫描行数是否远超返回行数）、Extra（是否含Using filesort、Using temporary） - 若发现
type=range但rows=50000，说明索引区分度差，可能需要联合索引或覆盖索引 - 若
Extra出现Using where; Using index condition，说明用了 ICP，是健康信号；若只有Using where，则索引未下推，考虑调整索引顺序
四、把分析动作固化为运维闭环
单次分析治标，机制建设才治本：
- 每天凌晨用 cron 跑一次 pt-query-digest，生成带日期后缀的报告，自动邮件推送前 5 条耗时最高的语句
- 在 Prometheus 中采集
slow_queries全局状态变量 + 自定义慢查数量指标，Grafana 面板设置 15 分钟突增告警 - 上线前 SQL 审核流程中，强制要求提供对应语句的 EXPLAIN 结果及 pt-query-digest 归类 ID，无依据不放行
- 对反复出现在 Top 3 的指纹 SQL，建专项优化看板，跟踪其
avg_latency和exec_count变化趋势
