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 和开发者的基本功。

配置步骤

  1. 开启慢查询日志: 设置 slow_query_log = 1。
  2. 设置阈值: 调整 long_query_time,生产环境建议设为 1 秒或更低。
  3. 指定日志路径: 配置 slow_query_log_file。
  4. 记录未使用索引的查询: 开启 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) 指定日志文件路径 慢查询日志生成 记录 Query_time / Lock_time / Rows_examined mysqldumpslow pt-query-digest 直接查看日志文件 诊断结果 识别慢 SQL / 索引问题 / 锁等待 优化反馈 持续监控与调优 调整阈值 / 优化索引

上图展示了从慢查询日志配置到诊断优化的完整闭环。核心要点是:配置 → 采集 → 分析 → 诊断 → 优化 → 再监控,形成持续改进的良性循环。

实战要点:
  • 生产环境建议将 long_query_time 设置为 1 秒,高并发核心业务可设为 0.5 秒。
  • 开启 log_queries_not_using_indexes 可以捕获全表扫描的查询,即使它们执行很快。
  • 慢查询日志会消耗磁盘 I/O,建议单独挂载磁盘或使用远程日志服务。
  • 定期使用 pt-query-digest 生成周报,跟踪慢查询趋势。