MySQL慢查询：pt-query-digest分析报告

开启慢查询日志并准备分析数据

MySQL慢查询日志是定位性能瓶颈的核心依据，它会记录执行时间超过阈值的SQL语句。配置时需关注三个关键参数：slow_query_log控制开关，long_query_time设定超时阈值（默认10秒，生产环境通常设为1或0.5秒），slow_query_log_file指定日志路径。可通过修改my.cnf持久化配置，或使用SET GLOBAL命令动态开启。配置完成后，务必执行SHOW VARIABLES LIKE 'slow_query%'确认状态为ON，并检查日志文件权限与磁盘空间。为获取有效分析样本，建议在业务低峰期保持日志开启数小时，或通过压测工具模拟真实负载，确保日志中包含足够多的高频与高耗时SQL，为后续pt-query-digest提供高质量原始数据。

使用pt-query-digest生成慢查询分析报告

pt-query-digest是Percona Toolkit中的核心组件，可通过系统包管理器或官方源码安装。基础用法为直接指定慢查询日志路径并输出报告文件。报告按Query ID聚合，核心指标包括总响应时间、调用次数、平均响应时间、锁时间及扫描行数。分析时应优先关注总耗时占比高或执行频率极高的SQL，而非单纯看单次最慢记录。例如某查询单次仅零点二秒但日调用十万次，其总负载远超单次耗时五秒的偶发查询。通过排序与过滤，可快速锁定对系统资源消耗最大的Top SQL，为后续优化提供明确目标。

结合执行计划定位SQL性能瓶颈

从报告中提取重点SQL后，需使用EXPLAIN命令深入分析其执行计划。重点关注type字段，若显示ALL则代表全表扫描，通常因缺失索引或索引失效导致；key字段显示实际使用的索引，若为NULL则需排查；rows反映优化器预估扫描行数，数值过大往往意味着数据倾斜或统计信息陈旧；Extra中的Using filesort或Using temporary提示存在排序或临时表开销，会显著拖慢查询。例如当WHERE条件包含函数包裹列时，索引将失效。此时可通过添加合适索引、改写查询逻辑或更新表统计信息来消除瓶颈，确保执行计划走ref或range路径。

优化后复测并解读报告变化

完成索引添加或SQL改写后，必须重新采集慢查询日志并运行pt-query-digest进行对比验证。可通过时间参数截取优化后的数据窗口，或使用日志轮转机制隔离新旧数据。对比前后报告时，重点观察目标Query ID的总耗时占比、平均响应时间及扫描行数是否显著下降。例如优化前某查询总耗时占全局大部分且扫描行数超百万，优化后占比降至极低水平且扫描行数降至百级，执行计划由全表扫描转为索引查找，即证明优化有效。若指标未改善，需检查索引是否命中或是否存在隐式类型转换，避免盲目上线。

生产环境分析中的常见误区与避坑

生产环境分析切忌唯最慢论，单次耗时极长但日执行仅一次的SQL对整体负载影响有限，应综合评估总耗时、执行频率与CPU及IO消耗。需注意慢查询日志的时间范围与采样偏差，日志仅记录超阈值SQL，可能遗漏大量临界慢查询。pt-query-digest默认会对SQL进行指纹化处理，将具体参数替换为占位符，分析时需结合业务上下文确认实际参数分布。此外历史日志反映的是过去负载，优化决策需结合实时监控与业务峰谷特征。避免过度添加索引导致写入性能下降，每次优化后务必进行全链路验证。