使用
pt-query-digest工具来分析MySQL慢查询日志，这基本上是数据库性能优化领域的一个标准操作了。它能把那些零散、难以直接阅读的慢查询记录，聚合、分类并生成一份清晰的报告，帮助我们快速定位到真正拖慢系统性能的SQL语句，而不是大海捞针般地逐条检查。在我看来，这不仅仅是一个工具，更像是一个帮你从海量数据中提炼出关键信息的智能助手，极大地提升了排查效率。
解决方案
要有效地利用
pt-query-digest，我们首先得确保MySQL的慢查询日志是开启的，并且配置得当。这包括设置
slow_query_log = ON，以及一个合适的
long_query_time值——这个值决定了查询执行超过多少秒才会被记录下来。通常，我倾向于从一个相对保守的值开始，比如1秒或0.5秒，然后根据实际业务的响应时间要求和日志量进行调整。
log_output = FILE也是必须的，因为
pt-query-digest主要处理文件形式的日志。
安装Percona Toolkit后，使用
pt-query-digest分析慢查询日志非常直接。最基本的命令是：
pt-query-digest /path/to/mysql-slow.log > slow_query_report.txt
这个命令会读取指定路径下的慢查询日志文件，然后将分析结果输出到一个文本文件。当然，这只是个开始。实际使用中，我们经常会用到一些参数来精炼分析范围，比如：
--limit 100%
: 默认只分析日志的前10%，这个参数确保分析所有数据。--since '2023-01-01 00:00:00'
和--until '2023-01-02 00:00:00'
: 分析特定时间段内的日志，这在排查某个时间点性能问题时非常有用。--group-by digest
: 这是默认行为，按查询模式（digest）分组。--filter '($event->{Bytes} > 1024)': 过滤掉一些不感兴趣的查询，比如只看返回字节数大于1KB的。
报告生成后，核心在于解读。它会给出一个整体统计，包括总查询时间、总锁时间等，然后列出按“查询模式”聚合的慢查询列表。每个模式下，你会看到该类查询的总执行时间占比、平均执行时间、最大执行时间、执行次数、锁时间、扫描行数、返回行数等等。我通常会优先关注那些
Query_time占比最高、
Calls次数多但
Query_time不一定最长的（因为一个频繁执行的“小慢”查询可能比一个偶尔执行的“大慢”查询影响更大），以及
Rows_examined与
Rows_sent比例异常高的查询——这往往意味着缺少索引。 如何高效配置MySQL慢查询日志以配合pt-query-digest？
配置MySQL慢查询日志，在我看来，不是简单地打开开关，而是要找到一个平衡点。设想一下，如果
long_query_time设置得太低，比如0秒，那日志文件会瞬间膨胀到无法处理，
pt-query-digest跑起来也会非常吃力，而且大部分记录可能都是无关紧要的。反之，如果设置得太高，比如10秒，你可能会错过一些虽然不至于“非常慢”但累积起来却对系统造成巨大压力的查询。
我的经验是，通常可以从1秒开始，对于一些对响应时间要求极高的系统，甚至可以降到0.1或0.5秒。但更重要的是，要结合业务的SLA（服务等级协议）来决定。如果你的应用要求所有请求在2秒内返回，那么将
long_query_time设置为1秒就很有意义，这样你就能提前发现潜在的瓶颈。
另外两个非常重要的配置是
log_queries_not_using_indexes和
min_examined_row_limit。前者顾名思义，会记录那些没有使用索引的查询，这简直是发现“漏网之鱼”的神器。很多时候，一个查询本身不慢，但因为它没有走索引，导致扫描了大量行，一旦数据量上去，它就会变成一个定时炸弹。
min_examined_row_limit则可以帮助我们过滤掉那些虽然没走索引但只扫描了几行数据的查询，避免日志中出现过多噪音。
别忘了日志文件的管理。慢查询日志文件可能会非常大，你需要考虑使用
expire_logs_days来自动清理旧日志，或者结合操作系统的
logrotate工具进行定期轮换和压缩，否则磁盘空间很快就会被耗尽。 pt-query-digest报告中哪些关键指标最值得关注？
拿到
pt-query-digest的报告，一开始可能会觉得信息量有点大，但只要抓住几个核心指标，很快就能找到方向。对我来说，有几个数据是每次必看的：
PIA
全面的AI聚合平台，一站式访问所有顶级AI模型
226
查看详情
首先，
Query_time，无论是总时间占比还是平均执行时间，都是最直观的性能指标。那些占据总查询时间大部分的查询，无疑是优化的首要目标。但仅仅看总时间还不够，还要看
Calls，也就是这个查询被执行了多少次。一个查询平均执行时间很短，但如果它被调用了百万次，那么它累积的总时间可能比一个平均执行时间很长但只执行了几次的查询还要多。
其次，
Lock_time也是一个非常关键的指标。如果一个查询的
Lock_time很高，这意味着它在执行过程中长时间地持有了锁，导致其他查询或事务不得不等待。这通常指向并发问题，可能需要检查事务隔离级别、索引策略或者是否存在长时间运行的写操作。
再者，
Rows_examined与
Rows_sent的比例非常能说明问题。
Rows_examined是MySQL为了找到结果而扫描的行数，而
Rows_sent是实际返回给客户端的行数。如果
Rows_examined远大于
Rows_sent，那就很可能存在索引缺失、索引失效或者查询条件不够精准的问题。例如，扫描了100万行却只返回了10行，这效率显然很低。
最后，我还会关注
tmp_tables和
tmp_disk_tables。当MySQL无法在内存中完成某些操作（如复杂的JOIN、GROUP BY或ORDER BY）时，它会创建临时表，如果内存不足，甚至会把临时表写到磁盘上。
tmp_disk_tables的出现几乎总是一个性能警示，因为它意味着大量的磁盘I/O，这通常比内存操作慢几个数量级。 除了慢查询日志，pt-query-digest还能分析哪些数据源？
pt-query-digest的强大之处在于，它不仅仅是一个慢查询日志分析器。它的设计理念使其能够处理各种格式的MySQL查询流，这大大拓宽了它的应用场景。
除了我们最常用的慢查询日志，它其实也能处理通用查询日志（General Query Log）。不过，通用查询日志记录了所有发送到MySQL服务器的查询，其信息量巨大，通常只用于调试或审计，而不是性能分析，因为大部分查询都是快速的，分析它会产生大量的噪音。
更高级一点，
pt-query-digest还能直接从
SHOW PROCESSLIST的输出中分析正在运行的查询。你可以结合
pt-stalk这样的工具，定期抓取
SHOW PROCESSLIST的输出，然后将其管道（pipe）给
pt-query-digest进行实时或准实时分析，找出当前正在拖慢系统的查询。例如：
pt-stalk --function=show-processlist --iterations=10 --interval=1 | pt-query-digest --type=processlist
这会在10秒内每秒抓取一次
SHOW PROCESSLIST的输出，然后将这些“快照”喂给
pt-query-digest，分析出在这10秒内最活跃、最耗时的查询模式。
再往深了说，
pt-query-digest甚至能解析通过
tcpdump抓取的MySQL网络流量。这在某些特定场景下非常有用，比如你没有服务器的SSH访问权限，或者无法修改MySQL配置来开启慢查询日志，但你可以通过网络层监听MySQL的通信。你需要捕获MySQL协议的数据包，然后指定
--type=tcpdump参数让
pt-query-digest去解析。这无疑是一个非常技术性和底层的用法，但它展现了工具的灵活性。
所以，别把
pt-query-digest仅仅看作一个“慢日志分析器”，它实际上是一个通用的MySQL查询模式分析引擎，只要能把查询流以它能理解的格式提供给它，它就能为你提供有价值的洞察。这使得它在数据库性能诊断工具箱中占据了不可替代的位置。
以上就是使用pt-query-digest工具分析MySQL慢查询日志报告的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： mysql 操作系统 工具 ssl sql语句 talk sql mysql Filter Event 并发 数据库 tcpdump 性能优化 ssh 大家都在看： MySQL内存使用过高（OOM）的诊断与优化配置 MySQL与NoSQL的融合：探索MySQL Document Store的应用 如何通过canal等工具实现MySQL到其他数据源的实时同步？ 使用Debezium进行MySQL变更数据捕获（CDC）实战 如何设计和优化MySQL中的大表分页查询方案
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。