1.1 慢查询基础:定义、危害与日志体系
慢查询(Slow Query)是数据库性能问题的核心信号。本章从最基础的概念出发,帮助学员建立对慢查询的完整认知,并掌握日志配置与分析方法。
1.1.1 什么是慢查询
慢查询是指执行时间超过预设阈值的 SQL 语句。在 MySQL 中,这个阈值由参数 long_query_time 控制,默认值为 10 秒。任何执行时间超过该值的查询都会被记录到慢查询日志中。
核心定义: 慢查询 = 执行耗时 > long_query_time 的 SQL 语句。它不仅是性能瓶颈的直接体现,更是数据库健康度的关键指标。
慢查询的典型特征包括:
- 响应时间长: 用户感知延迟明显,通常超过 1 秒即需关注。
- 资源消耗高: 占用大量 CPU、内存、磁盘 I/O 或网络带宽。
- 锁等待严重: 长时间持有锁,阻塞其他会话,引发连锁反应。
- 扫描行数多: 全表扫描或索引使用不当,导致数据访问效率低下。
1.1.2 慢查询的危害
慢查询的危害远不止“查询慢”本身,它往往引发系统性风险:
| 危害维度 | 具体表现 | 影响范围 |
|---|---|---|
| 用户体验下降 | 页面加载超时、接口响应缓慢、操作卡顿 | 前端用户直接感知 |
| 数据库负载飙升 | CPU 使用率 100%、磁盘 I/O 打满、连接池耗尽 | 数据库实例稳定性 |
| 锁竞争与死锁 | 慢查询长时间持有行锁或表锁,阻塞其他事务 | 并发事务吞吐量 |
| 主从延迟加剧 | 慢查询在从库重放时同样耗时,导致主从数据不一致 | 读写分离架构可靠性 |
| 系统雪崩风险 | 单个慢查询拖垮数据库,进而导致应用服务连锁故障 | 整体系统可用性 |
⚠️ 避坑提示: 很多团队只关注慢查询对“查询”本身的影响,却忽略了它对“写入”和“锁”的间接破坏。一个慢查询可能让整个数据库的 TPS 从 5000 骤降到 200。
1.1.3 慢查询日志配置与查看方法
MySQL 的慢查询日志是诊断性能问题的第一手资料。正确配置和解读日志,是 DBA 和开发者的基本功。
配置步骤
- 开启慢查询日志: 设置
slow_query_log = 1。 - 设置阈值: 调整
long_query_time,生产环境建议设为 1 秒或更低。 - 指定日志路径: 配置
slow_query_log_file。 - 记录未使用索引的查询: 开启
log_queries_not_using_indexes = 1。
-- 查看当前慢查询配置
SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';
-- 动态开启慢查询日志(重启后失效)
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 1;
-- 永久配置(需修改 my.cnf 并重启)
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 1
log_queries_not_using_indexes = 1
查看方法
慢查询日志是纯文本文件,可直接查看,但更推荐使用专用工具:
- mysqldumpslow: MySQL 自带工具,支持按执行时间、锁定时间、扫描行数等维度汇总。
- pt-query-digest: Percona Toolkit 中的利器,提供更丰富的分析和报表。
- 直接查看日志文件: 使用
tail -f实时监控。
# 使用 mysqldumpslow 分析慢查询日志
mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log
# 使用 pt-query-digest 生成详细报告
pt-query-digest /var/log/mysql/slow-query.log
日志内容解读
一条典型的慢查询日志记录包含以下关键信息:
| 字段 | 示例值 | 说明 |
|---|---|---|
| Query_time | 12.345678 | 查询总执行时间(秒) |
| Lock_time | 0.000123 | 锁等待时间(秒) |
| Rows_sent | 1000 | 返回给客户端的行数 |
| Rows_examined | 500000 | 扫描的行数(关键指标) |
| Rows_affected | 0 | 影响的行数(DML 语句) |
💡 经验法则: 当
Rows_examined 远大于 Rows_sent 时,说明查询没有有效利用索引,这是最常见的慢查询成因。
上图展示了从慢查询日志配置到诊断优化的完整闭环。核心要点是:配置 → 采集 → 分析 → 诊断 → 优化 → 再监控,形成持续改进的良性循环。
实战要点:
- 生产环境建议将
long_query_time设置为 1 秒,高并发核心业务可设为 0.5 秒。 - 开启
log_queries_not_using_indexes可以捕获全表扫描的查询,即使它们执行很快。 - 慢查询日志会消耗磁盘 I/O,建议单独挂载磁盘或使用远程日志服务。
- 定期使用
pt-query-digest生成周报,跟踪慢查询趋势。