慢查询日志分析需四步：一查启用状态与阈值（如long_query_time=1.0）；二用pt-query-digest聚合分析Top SQL；三借EXPLAIN定位执行瓶颈；四结合QPS、监控验证真实影响。
慢查询日志是定位性能瓶颈最直接的入口，关键不在于“有没有开”，而在于“怎么筛、怎么看、怎么归因”。MySQL 默认关闭慢查询日志，开启后需结合合理阈值与结构化分析，才能高效识别真正拖垮系统的 SQL。
一、确认慢查询日志已启用并配置合理
先检查是否生效，再看记录是否“有用”：
- 查看当前状态：执行 SHOW VARIABLES LIKE 'slow_query_log%'; 和 SHOW VARIABLES LIKE 'long_query_time';
- 建议阈值设置：线上系统通常设为 long_query_time = 1.0（秒），高并发场景可调至 0.5；注意该值对微秒级精度敏感（MySQL 5.6+ 支持毫秒）
- 确保记录完整：开启 log_queries_not_using_indexes = ON 可捕获缺失索引的查询，但会显著增加日志量，建议阶段性开启
二、用 pt-query-digest 快速聚合分析日志
原生日志文本杂乱，人工翻查效率极低。Percona Toolkit 中的 pt-query-digest 是事实标准工具：
- 基础用法：命令 pt-query-digest /var/lib/mysql/slow.log 输出按响应时间排序的 Top SQL 汇总
- 重点关注字段：Rows_examined（扫描行数）、Rows_sent（返回行数）、Query_time（平均耗时）、Lock_time（锁等待）、QPS（出现频次）
- 实用技巧：加 --since "2024-06-01 00:00:00" 限定时间范围；用 --filter '$event->{Rows_examined} > 1000' 过滤低价值语句
三、从执行计划（EXPLAIN）反推慢因
日志里看到慢 SQL 后，不能只改写法，必须看 MySQL 实际怎么执行它：
- 核心关注点：type（访问类型，ALL/INDEX 最差，const/ref 最优）、key（是否命中索引）、rows（预估扫描行数）、Extra（常见陷阱如 Using filesort、Using temporary、Using join buffer）
-
典型问题模式：
- WHERE 条件列没索引 → 补索引（注意联合索引顺序）
- ORDER BY 字段未包含在索引中 → 考虑覆盖索引或避免 SELECT *
- JOIN 多表时驱动表选择错误 → 用 STRAIGHT_JOIN 或调整 JOIN 顺序
- 隐式类型转换导致索引失效 → 检查字段类型与参数是否严格一致（如 VARCHAR vs INT）
四、结合业务上下文验证真实影响
一条 SQL 在日志里排前三，未必是“罪魁祸首”：
- 区分调用量级：QPS=100 的慢 SQL 比 QPS=1 的慢 10 倍更危险；pt-query-digest 的 Count 列就是答案
- 看资源消耗分布：用 pt-query-digest --report-format profile 查 CPU/IO 占比，判断是计算密集型还是 I/O 瓶颈
- 关联监控数据：将慢 SQL 时间戳与 Prometheus 中的 QPS、连接数、InnoDB Row Operations 曲线对齐，确认是否触发了雪崩或锁竞争
