1. 慢查询概述
1.1 什么是慢查询
慢查询（Slow Query）是指执行时间超过预设阈值或消耗过多系统资源的数据库查询语句。在联机事务处理（OLTP）场景中，慢查询通常表现为单次查询响应时间超过 100ms 或 1s，而在联机分析处理（OLAP）或批处理场景中，阈值可能放宽到 10s 甚至更长。慢查询的本质是查询计划未能高效利用索引、内存或 CPU，导致数据库引擎需要扫描大量数据页或进行低效的临时排序、全表扫描。
关键定义： 慢查询 = 执行时间 > 阈值（如 long_query_time） 或 扫描行数 > 预期值（如 rows_examined > 10000）。
1.2 慢查询的典型特征
慢查询并非随机出现，它们通常具备以下可量化的特征，SRE 和 DBA 可以通过监控指标快速识别：
| 特征维度 | 典型表现 | 常见原因 |
|---|---|---|
| 执行时间 | 单次查询耗时 > 1s，甚至达到 10s+ | 缺少索引、数据倾斜、锁等待 |
| 扫描行数 | rows_examined 远大于 rows_sent（如 10 万行扫描只返回 10 行） | 索引选择性差、非覆盖索引回表 |
| 临时表/排序 | Using temporary；Using filesort 出现在 EXPLAIN 输出中 | GROUP BY/ORDER BY 无索引、内存临时表溢出到磁盘 |
| 锁竞争 | 大量行锁等待、死锁超时、事务长时间未提交 | 长事务、间隙锁冲突、热点行更新 |
| 资源消耗 | CPU 使用率飙升、IOPS 打满、Buffer Pool 命中率下降 | 全表扫描、大范围索引扫描、排序溢出 |
SRE 监控要点： 建议将
slow_queries 指标与 rows_examined、lock_time 联合告警，避免仅依赖执行时间单一维度。
1.3 慢查询对系统稳定性的影响
慢查询的危害远不止“查询慢”本身。在连接池和微服务架构下，慢查询会像“多米诺骨牌”一样引发连锁故障。下图展示了慢查询如何从数据库层向上传导，最终导致整个服务链路雪崩：
从传导链可以看出，慢查询的破坏力具有明显的放大效应：
- 数据库层：慢查询长时间持有数据库连接，占用线程和锁资源，导致数据库连接池水位上升。
- 应用层：应用连接池中的连接被慢查询长期占用，后续请求无法获取连接，开始排队等待或直接超时。
- 服务层：上游服务因下游超时而触发重试机制，重试流量进一步加剧数据库压力，形成正反馈循环。
- 业务层：最终表现为接口响应时间飙升、错误率上升、甚至整个服务链路雪崩。
实战案例： 某电商平台大促期间，一条未命中索引的订单查询语句执行时间从 200ms 飙升至 8s，导致应用连接池 200 个连接在 30 秒内全部被占满。上游网关重试策略又将流量放大 3 倍，最终数据库 CPU 打满，核心交易链路中断 12 分钟。事后分析发现，该查询扫描了 500 万行数据，仅返回 20 行结果。
1.4 慢查询与连接池、熔断降级的关联
理解慢查询的传导机制是后续调优的基础。本课程后续章节将围绕以下核心问题展开：
| 调优方向 | 核心问题 | 本章节关联 |
|---|---|---|
| 连接池参数 | 如何设置最大连接数、超时时间、空闲回收策略，避免被慢查询拖垮？ | 第 2-5 章 |
| 熔断降级 | 如何识别慢查询引发的异常状态，快速切断故障链路？ | 第 6-8 章 |
| 慢查询治理 | 如何通过索引优化、SQL 改写、读写分离从根本上减少慢查询？ | 第 9-12 章 |
学习建议： 在进入参数调优之前，请确保你的监控系统已经能够采集
Threads_connected、Threads_running、Slow_queries、Innodb_row_lock_current_waits 等关键指标。这些数据是后续调优决策的依据。