当前位置：首页 > ai >正文

性能测试工具-Slow Query Log

ai 2025/9/1 8:07:50

一、它是什么？为什么测试工程师必须掌握？

慢查询日志 是 MySQL 内置的一种日志功能，用于记录执行时间超过指定阈值（long_query_time）的所有 SQL 语句。

对你（测试工程师）的核心价值：

精准定位瓶颈：当性能测试发现接口响应慢时，能快速判断是否是数据库拖慢了后腿，并直接揪出“元凶”SQL。
提供无可辩驳的证据：在提交给开发的 Bug 报告中，附上一条具体的慢 SQL 及其执行时间，比单纯说“接口慢了 2 秒”更有力。
优化效果验证：在开发对 SQL 进行优化（如加索引）后，你可以再次执行测试，通过对比优化前后慢日志中该 SQL 的执行时间，量化验证优化的效果。
发现潜在问题：可以发现那些在测试数据量小时运行正常，但上线后随着数据量增长必然会出问题的 SQL（如全表扫描）。

如何配置与开启（测试环境）

慢查询日志默认是关闭的，需要在测试环境的 MySQL 配置中开启。

1. 临时开启（重启失效，适合临时测试）

@sql

-- 1. 查看慢查询日志相关参数（确认当前状态）
SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';-- 2. 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';-- 3. 设置慢查询时间阈值（单位：秒），例如设置超过1秒就算慢查询
SET GLOBAL long_query_time = 1;-- 4. 设置日志文件路径（可选，不设置则使用默认位置）
SET GLOBAL slow_query_log_file = '/var/lib/mysql/slow.log';

2. 永久生效（修改配置文件）
修改 MySQL 的配置文件 my.cnf (Linux) 或 my.ini (Windows)：

@ini

[mysqld]
# 开启慢查询日志
slow_query_log = 1
# 指定慢查询日志文件路径
slow_query_log_file = /var/lib/mysql/slow.log
# 设置慢查询时间阈值(0.1秒=100毫秒，对高性能应用很常见)
long_query_time = 0.1
# 记录未使用索引的查询（非常重要！即使执行快也可能是潜在问题）
log_queries_not_using_indexes = 1

修改后需要重启 MySQL 服务。

测试环境建议：将 long_query_time 设置得小一些（如 0.1 秒），以便捕获更多潜在问题的 SQL。切勿在生产环境轻易设置 log_queries_not_using_indexes，否则日志量可能会巨大。

三、如何分析慢查询日志（核心技能）

日志内容看起来可能很乱，但核心是抓住几个关键信息。一条典型的慢日志记录如下：

@sql

# Time: 2023-10-27T06:12:13.123456Z
# User@Host: test_engineer[test_engineer] @  [192.168.1.100]  Id:  1234
# Query_time: 12.345678  Lock_time: 0.001234 Rows_sent: 10  Rows_examined: 10000000
SET timestamp=1698387133;
SELECT * FROM `orders` WHERE `status` = 'pending' AND `create_time` > '2023-10-20' ORDER BY `id` DESC;

作为测试工程师，你需要关注这些字段：

字段	示例值	含义与分析	给开发的建议方向
`Query_time`	`12.345678`	SQL 实际执行时间（单位：秒）。这是最直接的证据。	“这条 SQL 执行了 12 秒，导致接口超时。”
`Rows_examined`	`10000000`	**SQL 执行过程中扫描了多少行数据。这是关键中的关键！**	“为获取10条结果，扫描了1000万行，怀疑缺失有效索引。”
`Rows_sent`	`10`	返回给了客户端多少行数据。对比 `Rows_examined`，比值越小问题越大。
`Lock_time`	`0.001234`	等待锁的时间。如果这个时间很长，说明存在严重的锁竞争。	“事务持有锁时间过长，可能并发逻辑有问题。”
`SET timestamp`	`1698387133`	SQL 执行的具体时间点。可以和你性能测试工具（如 JMeter）的报告时间点关联。	“在晚高峰压测期间，此SQL频繁出现。”
`SQL 语句`	`SELECT * FROM ...`	****问题的根本。	“建议为 `status` 和 `create_time` 字段添加联合索引。”

分析方法：

直接查看：如果日志不大，可以用 vim, less 等命令直接查看，但效率低。

使用官方工具 mysqldumpslow：MySQL 自带的摘要分析工具，可以对日志进行归类统计。

@bash

# 得到返回记录集最多的10条SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/slow.log# 得到访问次数最多的10条SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/slow.log# 得到按照时间排序，并且包含'select'的前10条SQL
mysqldumpslow -s t -t 10 -g "select" /var/lib/mysql/slow.log

使用更强大的第三方工具 pt-query-digest：这是 Percona Toolkit 中的王牌工具，是分析慢查询日志的行业标准，强烈推荐。
@bash
```
pt-query-digest /var/lib/mysql/slow.log > slow_report.txt
```
它会生成一份非常详细的报告，包括：
- 总的查询时间和占比（哪些 SQL 拖慢了整个系统）
- 单个查询的统计信息（执行次数、最小/最大/平均时间）
- 执行时间的分布直方图

四、在性能测试工作流中的应用

测试前：在测试环境数据库中开启慢查询日志，并设置合理的阈值。
测试中：使用 JMeter、LoadRunner 等工具执行性能测试场景（如高并发下单、批量查询）。
测试后：
- 停止压测。
- 使用 pt-query-digest 分析慢日志，生成报告。
- 将报告中最耗时的 TOP N SQL 及其详细分析（扫描行数、执行时间等）作为附件，提交到性能 Bug 中。
- 在 Bug 描述中，清晰地将接口性能问题与具体的 SQL 瓶颈关联起来。
回归验证：
- 开发修复（如添加索引、优化 SQL 逻辑）后。
- 在同一测试环境、相同测试数据和相同测试场景下再次执行性能测试。
- 对比优化前后的慢日志：
  - 如果该 SQL 从未在日志中出现 → 优化成功。
  - 如果执行时间显著降低（如从 10s 降到 0.1s）→ 优化成功。
  - 如果 Rows_examined 大幅减少 → 优化成功。