如何分析慢查询日志？

wen IT资讯 2026-06-03 237

从定位到优化的完整实战指南

目录导读

什么是慢查询日志？为什么它如此重要？
如何开启与配置慢查询日志？
慢查询日志的核心字段解读
如何高效分析慢查询日志？（含工具推荐）
常见慢查询问题及优化策略
问答环节：你关心的慢查询问题解答
总结与行动建议

什么是慢查询日志？为什么它如此重要？

慢查询日志是数据库（以MySQL为例）记录执行时间超过预设阈值（如1秒）的SQL语句的日志文件，它是数据库性能诊断的“第一手证据”，能直接告诉你哪些查询正在拖垮系统。

如何分析慢查询日志？

为什么重要？

定位瓶颈：90%的数据库性能问题源于慢查询。
量化影响：通过记录执行时间、扫描行数等，能判断查询的“破坏力”。
优化依据：没有日志，优化就是盲人摸象。

问：慢查询日志会消耗大量磁盘空间吗？
答：取决于你的慢查询频率和保留时长，建议生产环境开启但设置合理阈值（如long_query_time=2秒），并定期轮转日志（如每日切割）。

如何开启与配置慢查询日志？

1 临时开启（重启失效）

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2;      -- 单位：秒，推荐1-5秒
SET GLOBAL log_queries_not_using_indexes = ON;  -- 记录未使用索引的查询

2 永久配置（修改my.cnf / my.ini）

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

关键参数解释：

long_query_time：时间阈值，建议从2秒起步，逐步下调。
log_queries_not_using_indexes：记录未命中索引的查询（即使执行很快）。
min_examined_row_limit：限制仅记录扫描行数超过指定值的查询（减少冗余日志）。

问：生产环境长期开启慢查询日志会不会影响性能？
答：几乎没有影响（写入日志为异步IO操作），但日志文件需定期清理，建议配置logrotate或数据库自带的slow_query_log_rotate。

慢查询日志的核心字段解读

一条典型的慢查询日志记录包含：

# Time: 2023-10-25T10:00:00.123456Z
# User@Host: root[root] @ localhost []
# Query_time: 5.234567  Lock_time: 0.001234  Rows_sent: 1000  Rows_examined: 500000
SET timestamp=1698213600;
SELECT * FROM orders WHERE status = 'pending' AND created_at > NOW() - INTERVAL 30 DAY;

字段含义：

Query_time：执行总时长（优化核心指标）。
Lock_time：锁等待时间（过高可能表示锁竞争）。
Rows_sent：返回结果行数（若远小于Rows_examined，说明“扫描多，返回少”）。
Rows_examined：扫描的总行数（重点排查项）。
SET timestamp：查询执行的时间戳（便于关联业务高峰期）。

问：Rows_examined远大于Rows_sent代表什么？
答：典型“全表扫描”或索引失效，如status字段无索引，导致需扫描50万行才返回1000条，优化方向：添加索引或改写查询。

如何高效分析慢查询日志？

1 手动分析（适用于小规模日志）

# 统计出现次数最多的前10条（按SQL指纹分组）
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
# 按查询时间排序
mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log

2 工具分析（推荐）

pt-query-digest（Percona Toolkit）
```
pt-query-digest /var/log/mysql/mysql-slow.log > analysis_report.txt
```
输出包括：
- 总体统计（总查询数、平均时间、最大时间）
- 按“查询指纹”分组，显示每个查询的占比、执行时间、扫描行数。
Slow Log Analyzer（如MySQL Enterprise Monitor或开源的Anemometer）
可视化展示，按时间段、执行频率、扫描行数排序。

3 分析要点

识别“大头”：关注执行时间总和最高的查询（而非次数最多）。
对比Rows_examined与Rows_sent：若差距>100倍，立即检查索引。
关注Lock_time：若超过Query_time的20%，检查锁等待（如行锁、表锁）。

问：pt-query-digest中的“Query_time distribution”是什么？
答：展示查询时间的分布比例，例如80%的查询在0.1秒内，但某查询耗时10秒，这就是需要优化的“异常点”。

常见慢查询问题及优化策略

1 未使用索引或索引失效

症状：Rows_examined极高，type=ALL（全表扫描）。

修复：

-- 添加复合索引（覆盖查询条件+排序字段）
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);

2 大量锁等待

症状：Lock_time接近或超过Query_time。
修复：
- 缩短事务时间,减少锁持有时间。
- 优化SQL（如将UPDATE拆分为批量操作）。

3 数据统计信息过时

症状：执行计划显示使用了索引，但Rows_examined仍很高。

修复：

ANALYZE TABLE orders;  -- 更新统计信息

4 子查询改为JOIN或EXISTS

原SQL：

SELECT * FROM a WHERE id IN (SELECT order_id FROM orders WHERE status='pending');

优化后：

SELECT a.* FROM a INNER JOIN orders ON a.id=orders.order_id WHERE orders.status='pending';

5 分页查询的深度翻页

问题：LIMIT 1000000, 20会导致扫描大量行。

优化：使用“延迟关联”或“游标分页”。

-- 延迟关联：先查主键，再回表
SELECT t.* FROM orders t JOIN (SELECT id FROM orders WHERE ... ORDER BY id LIMIT 1000000,20) AS tmp ON t.id=tmp.id;

问：复杂查询如何分析执行计划？
答：在慢查询前加EXPLAIN，关注type（最好为ref或range）、key（是否使用索引）、rows（预估扫描行数）。

问答环节：你关心的慢查询问题解答

Q1：关闭慢查询日志能提升数据库性能吗？
不能，慢查询日志的写入是异步的，几乎无开销，真正影响性能的是慢查询本身，关闭日志等于“装睡”。

Q2：pt-query-digest报告中的“pct”代表什么？
代表该查询占总查询次数的百分比，例如pct=5表示每100次慢查询中，该查询出现5次。

Q3：为什么long_query_time设为0.5秒后，日志数量暴增？
可能你的系统大量存在0.5-1秒的查询，建议先分析这些查询是否可优化，若不可优化（如大量小查询），可调高阈值到2秒，优先捉“大家伙”。

Q4：慢查询日志里出现了SET timestamp，但找不到对应代码？
可能是框架自动生成的SQL（如ORM映射），需结合general_log或监控工具定位API接口。

Q5：如何判断某个慢查询是偶发还是持续？
用pt-query-digest的--since和--until参数对比不同时间段的报告，若某查询只出现在某个时段，可能是后台任务或缓存失效。

总结与行动建议

分析慢查询日志的黄金步骤：

开启日志：配置long_query_time=2秒，记录未用索引查询。
定期分析：使用mysqldumpslow或pt-query-digest生成报告。
聚焦Top 5：优先优化执行总时间最长的SQL。
验证效果：优化后对比前后Query_time和Rows_examined。

关键提醒：

优化前备份并测试（可先在slave上SET long_query_time=0记录所有查询）。
索引不是万能药：过度索引会拖慢写入，平衡点在于“读写比例”。
业务层优化同样重要：如增加缓存、异步处理、分库分表。

最后一句：慢查询日志是数据库的“体检报告”，定期阅读它，你的系统会活得比竞争对手更久。