3. 慢查询成因分析：全表扫描、索引失效、锁等待、数据量过大、硬件瓶颈
慢查询是数据库性能劣化的核心诱因，也是连接池耗尽与熔断降级链条的起点。本章从数据库内核视角，系统拆解慢查询的五大成因：全表扫描、索引失效、锁等待、数据量过大与硬件瓶颈。理解这些成因，是后续压测场景设计与熔断策略调优的基础。
核心认知：慢查询并非单一原因导致，往往是多个因素叠加的结果。例如，索引失效引发全表扫描，全表扫描加剧锁竞争，锁等待又进一步拖慢查询，形成恶性循环。
3.1 全表扫描
全表扫描是数据库执行计划中最昂贵的操作之一。当查询无法利用索引时，数据库必须顺序读取表的所有数据页，逐行检查是否满足过滤条件。在数据量较大的表上，全表扫描的 I/O 开销与 CPU 开销呈线性增长。
| 对比维度 | 全表扫描 | 索引扫描 |
|---|---|---|
| I/O 次数 | 读取表的所有数据页 | 仅读取索引页 + 少量数据页 |
| 时间复杂度 | O(N)，N 为行数 | O(log N) 或更优 |
| 适用场景 | 小表、无合适索引、查询返回大部分行 | 选择性高的过滤条件 |
| 典型触发原因 | WHERE 条件无索引、隐式类型转换、函数包裹列 | 索引设计合理、查询条件匹配索引 |
压测观察点：在压测过程中，若数据库 CPU 使用率飙升但 QPS 不升反降，且监控显示磁盘读取量巨大，应优先怀疑全表扫描。使用
EXPLAIN 分析执行计划，关注 type 字段是否为 ALL。
3.2 索引失效
索引失效是慢查询的常见诱因。即使表上存在索引，若查询写法不当，优化器仍可能放弃索引而选择全表扫描。以下是索引失效的典型场景：
- 隐式类型转换：例如
WHERE varchar_col = 123，数据库会将列转换为数值类型，导致索引失效。 - 函数包裹索引列：例如
WHERE DATE(create_time) = '2024-01-01'，应改为WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'。 - LIKE 前置通配符：
WHERE name LIKE '%keyword'无法使用索引，而WHERE name LIKE 'keyword%'可以。 - 联合索引未遵循最左前缀：例如索引
(a, b, c)，查询条件只包含b和c时索引失效。 - OR 条件中存在非索引列：例如
WHERE indexed_col = 1 OR non_indexed_col = 2，优化器可能放弃索引。 - NOT IN / <> 操作：不等值操作通常无法使用索引。
压测陷阱：在压测脚本中，若参数化查询使用了错误的数据类型（如将数字参数以字符串形式传入），会触发隐式类型转换，导致索引失效。务必在压测前使用
EXPLAIN EXTENDED 验证执行计划。
3.3 锁等待
锁等待是并发场景下慢查询的重要成因。当多个事务同时操作同一行或同一范围的数据时，锁竞争会导致查询被阻塞，响应时间急剧上升。锁等待不仅影响当前查询，还会引发连锁效应：连接池中的连接被长时间占用，最终导致连接池耗尽。
| 锁类型 | 影响范围 | 典型场景 | 慢查询表现 |
|---|---|---|---|
| 行锁 | 单行或少量行 | UPDATE 同一行、SELECT FOR UPDATE | 查询等待时间 > 执行时间 |
| 间隙锁 | 索引范围 | 可重复读隔离级别下的范围查询 | 插入/更新被阻塞 |
| 表锁 | 整张表 | DDL 操作、MyISAM 引擎写操作 | 所有查询排队等待 |
| 元数据锁 | 表结构 | ALTER TABLE 与 DML 并发 | 查询卡在“Waiting for table metadata lock” |
诊断命令：MySQL 中可使用
SHOW ENGINE INNODB STATUS\G 查看锁等待信息，关注 LATEST DETECTED DEADLOCK 和 TRANSACTIONS 部分。压测时建议开启 innodb_lock_wait_timeout 监控，避免连接被无限阻塞。
3.4 数据量过大
数据量增长是慢查询的渐进式成因。即使索引设计合理，当表数据量达到千万级甚至亿级时，索引树的深度增加、数据页的 I/O 次数上升、内存缓冲池的命中率下降，都会导致查询性能退化。
- 索引深度增加：B+ 树索引的深度通常为 3~4 层，当数据量极大时可能达到 5 层，每次查询需要多一次 I/O。
- 缓冲池命中率下降：热数据无法全部驻留内存，导致频繁的磁盘读取。
- 排序与临时表：大数据量的
ORDER BY、GROUP BY、DISTINCT操作可能使用磁盘临时表，性能急剧下降。 - 分页查询偏移：
LIMIT 100000, 20需要扫描前 100020 行，即使有索引也无法跳过。
压测建议：压测数据量应模拟生产环境的规模（至少 80% 量级）。若压测数据量过小，索引深度和缓冲池命中率无法真实反映生产问题，压测结果会过于乐观。
3.5 硬件瓶颈
硬件瓶颈是慢查询的物理限制。即使 SQL 优化到位、索引设计合理，硬件资源不足仍会导致查询缓慢。常见的硬件瓶颈包括：
| 资源类型 | 瓶颈表现 | 监控指标 | 优化方向 |
|---|---|---|---|
| CPU | 查询执行时间长，上下文切换频繁 | CPU 使用率 > 80%、run queue 长度 | 优化 SQL、增加索引、升级 CPU |
| 内存 | 缓冲池命中率低，频繁磁盘 I/O | InnoDB buffer pool hit rate < 95% | 增加内存、优化数据访问模式 |
| 磁盘 I/O | 查询等待 I/O，磁盘利用率高 | iowait > 10%、磁盘吞吐量接近上限 | 使用 SSD、增加磁盘、优化查询减少 I/O |
| 网络 | 数据传输延迟大，连接超时 | 网络延迟、丢包率、带宽利用率 | 内网部署、减少数据传输量、使用连接池 |
压测误区：很多压测在低负载下进行，硬件资源充裕，无法暴露瓶颈。真正的压测应逐步增加并发，直到某个硬件资源成为瓶颈，此时观察慢查询的变化趋势，才能准确评估系统的承载上限。
3.6 成因关联与压测场景设计
五大成因并非孤立存在，它们在压测场景中相互关联。以下表格总结了各成因在压测中的典型表现与关联关系：
| 慢查询成因 | 压测典型表现 | 关联成因 | 压测场景设计建议 |
|---|---|---|---|
| 全表扫描 | 磁盘 I/O 飙升，CPU 使用率高，QPS 低 | 索引失效、数据量过大 | 构造无索引查询，观察连接池耗尽速度 |
| 索引失效 | 执行计划显示 type=ALL，响应时间波动大 | 全表扫描、数据量过大 | 使用函数包裹列、隐式类型转换触发失效 |
| 锁等待 | 连接数持续增长，事务等待时间长 | 全表扫描（锁范围扩大） | 并发 UPDATE 同一行，观察连接池耗尽 |
| 数据量过大 | 查询响应时间随数据量线性增长 | 全表扫描、硬件瓶颈 | 逐步增加数据量，观察性能拐点 |
| 硬件瓶颈 | 资源利用率达到上限，查询排队 | 所有成因均会加剧硬件压力 | 逐步增加并发，直到某个资源成为瓶颈 |
压测策略：建议按“单一成因 → 组合成因”的顺序设计压测场景。先分别验证每个成因对连接池和熔断的影响，再构造多成因叠加的复杂场景，模拟生产环境的真实故障模式。