慢查询基础：数据库慢查询的典型特征、常见原因
慢查询是数据库性能劣化的核心信号。在生产环境中，一条慢查询不仅会阻塞自身连接，还可能拖拽整个连接池、耗尽 CPU 或 IO 带宽，最终引发级联故障。理解慢查询的典型特征与根因，是后续定位与压测的基石。
2.1 慢查询的典型特征
慢查询并非仅指“执行时间长”，而是从多个维度暴露出的异常行为。以下特征可作为快速识别慢查询的雷达指标：
| 特征维度 | 典型表现 | 监控指标示例 |
|---|---|---|
| 响应时间 | 单条查询耗时远超基线（如从 5ms 飙升至 500ms） | p99 延迟、平均延迟 |
| 扫描行数 | 全表扫描或扫描大量无关行（如扫描 100 万行仅返回 10 行） | Rows Examined / Rows Sent 比值 |
| 临时表与排序 | Using temporary；Using filesort 出现在执行计划中 | Created_tmp_disk_tables 增长 |
| 锁等待 | 查询长时间处于 Waiting for table metadata lock 或行锁等待状态 | Innodb_row_lock_current_waits |
| CPU / IO 飙升 | 数据库 CPU 使用率突增，磁盘 IOPS 或 IO 延迟同步上升 | CPU 利用率、IO 等待时间 |
快速定位技巧： 在 MySQL 中开启
slow_query_log 并设置 long_query_time = 1（秒），配合 pt-query-digest 工具可自动聚合慢查询特征。
2.2 常见原因一：索引缺失
索引缺失是慢查询最常见的根因。当查询条件、排序或 JOIN 字段缺少合适索引时，数据库被迫执行全表扫描，扫描行数急剧膨胀。
2.2.1 索引缺失的典型场景
- WHERE 条件无索引： 如
SELECT * FROM orders WHERE status = 'PENDING'，若 status 列无索引，则全表扫描。 - 排序字段无索引：
ORDER BY created_at DESC导致 filesort，大量数据在内存或磁盘中排序。 - JOIN 关联列无索引： 驱动表与被驱动表的关联键缺少索引，导致嵌套循环扫描。
- 覆盖索引不足： 查询需要回表获取大量列，而索引无法覆盖所有字段。
案例： 某订单查询
SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 10 执行 2.3 秒。添加联合索引 (user_id, created_at) 后，执行时间降至 3 毫秒，扫描行数从 50 万降至 10 行。
2.3 常见原因二：锁竞争
锁竞争导致查询并非在执行数据读取，而是在排队等待锁资源。高并发写入场景下，锁冲突会急剧放大尾延迟。
2.3.1 锁竞争的主要类型
| 锁类型 | 触发场景 | 典型等待事件 |
|---|---|---|
| 行锁 | 多个事务并发更新同一行 | Innodb_row_lock_time |
| 间隙锁 | RR 隔离级别下范围查询加锁 | Waiting for gap lock |
| 元数据锁 | DDL 操作与 DML 并发 | Waiting for table metadata lock |
| 表锁 | MyISAM 表或显式 LOCK TABLES | Table_locks_waited |
避坑提示： 长事务持有行锁不释放，会导致后续查询大量堆积。监控
information_schema.innodb_trx 中运行超过 5 秒的事务，及时 kill 或优化。
2.4 常见原因三：数据倾斜
数据倾斜指数据在分区、分片或索引键上分布极度不均。少量节点或分区承载了绝大部分查询压力，导致整体性能受限于热点。
2.4.1 数据倾斜的典型表现
- 分区倾斜： 按日期分区时，某一天的数据量是其他日期的 100 倍，查询该分区时扫描行数剧增。
- 分片倾斜： 在分库分表场景下，某个分片的数据量远超其他分片，该分片成为性能瓶颈。
- 索引键倾斜： 索引列的值分布不均，如 status 列 99% 为 'COMPLETED'，1% 为 'PENDING'，查询 PENDING 时索引效率极低。
案例： 某日志表按
log_level 分区，'ERROR' 分区仅 100 行，'INFO' 分区 1 亿行。查询 WHERE log_level = 'INFO' 时扫描全分区，耗时 12 秒。改为按时间分区后，查询耗时降至 200 毫秒。
2.5 慢查询根因分类总览
以下 SVG 图展示了慢查询三大根因及其内部子因的层级关系，帮助建立系统化的排查框架。
2.6 慢查询排查流程
以下流程图展示了从发现慢查询到定位根因的标准化排查步骤，适用于日常运维与应急响应。
2.7 慢查询排查清单
将以下清单作为日常巡检与应急排查的检查项，可快速覆盖慢查询的三大根因：
| 排查步骤 | 检查项 | 工具 / 命令 |
|---|---|---|
| 1 | 是否开启慢查询日志 | SHOW VARIABLES LIKE 'slow_query_log' |
| 2 | 慢查询日志中 TOP N 查询 | pt-query-digest /var/log/mysql/slow.log |
| 3 | 执行计划是否使用索引 | EXPLAIN SELECT ... 检查 type、key、rows |
| 4 | 是否存在锁等待 | SHOW ENGINE INNODB STATUS\G 或 performance_schema |
| 5 | 数据分布是否均匀 | SELECT COUNT(*) ... GROUP BY partition_key |
| 6 | 索引统计信息是否过期 | SHOW INDEX FROM table_name + ANALYZE TABLE |
最佳实践： 建议将慢查询日志与 APM 系统（如 Prometheus + Grafana）集成，设置 p99 延迟告警阈值，在慢查询影响用户体验前主动发现。