用 pt-query-digest 分析慢查询

发布时间:2025-12-10 10:47

## 场景 数据库整体变慢，慢日志里躺着成百上千条语句，逐条看既看不完也分不出主次。pt-query-digest 把慢日志聚合分析：相同形态的语句归为一类，按总耗时排序，输出一份谁最拖后腿的报告。优化精力有限，先打哪条，报告直接给答案。它把个体噪声折叠成模式统计，偶发的慢查询不再干扰判断，反复出现的高耗形态自然浮到榜首。 ## 步骤清单 先确认慢日志已开启，阈值根据业务定，一般从一秒起步收紧。 ``` SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; ``` 采集一段时间后运行分析。 ``` pt-query-digest /var/log/mysql/slow.log > report.txt ``` 报告按语句总耗时降序排列，每类语句给出执行次数、平均耗时、扫描行数与返回行数等统计。 ## 读报告与验证 先看排名前几的语句类，判断顺序有三步：看总耗时占比，头部语句通常吃掉大半时间，优化它收益最大；看扫描行数与返回行数之比，比值悬殊说明索引没命中，扫了几十万行只回几行；看次数与单次耗时的组合，高频短查询累加成的总量常被忽视。锁定目标后按常规路径优化，加索引或改写语句，改完清空慢日志再采一段对比，同类语句的排名与耗时降下来才算数。一轮报告只处理头部两三类语句即可，改完再跑一次分析，榜单会重新洗牌，迭代两三轮通常就能消化掉大部分总耗时。 ## 注意事项 分析工具本身只读日志，对库无压力，可以放心在生产跑；但采集窗口要有代表性，只采十分钟空闲期，报告会漏掉高峰才出现的问题。排名里只出现一次的长查询参考价值低，别为孤例大动干戈。索引优化之外，报告还会暴露一类纯架构问题：同类语句次数极高而单次很快，说明应用在循环里逐条查询，改批量读取比任何索引都有效。顺云云服务器上建议把这项分析做成每月例行，慢日志定期滚动归档，趋势变化比单次快照更能说明问题。