数据库瓶颈怎么查
压测吞吐上不去、延迟一路攀升时，先看数据库的四类信号：慢查询（执行计划）、锁等待（阻塞链）、连接池（排队还是耗尽）、资源（CPU 与磁盘 IO）。多数「应用慢」最终落到一条没有合适索引的 SQL，或一把被长事务占着的锁；定位靠证据——压测时同步采集的慢日志与指标。
基本信息
| 信号一 | 慢查询日志与慢语句 TOP：按总耗时排序，而不是单次耗时 |
|---|---|
| 信号二 | 锁等待：MySQL 看 InnoDB 状态与元数据锁，PostgreSQL 查 pg_locks |
| 信号三 | 连接数：活跃、空闲、等待三个数量，池上限与数据库上限对齐 |
| 信号四 | 资源：数据库 CPU、磁盘 IO、缓冲命中率曲线 |
| 常见根因 | 缺索引、隐式类型转换让索引失效、N 加 1 查询、大事务、批量提交 |
| 采集时机 | 压测同时采集，事后靠猜会让优化无法对比 |
排查语句示例
排查语句示例
-- MySQL：看当前连接与执行状态
SHOW PROCESSLIST;
-- 执行计划：关注 type=ALL 全表扫描与 rows 估计值
EXPLAIN SELECT * FROM orders WHERE user_id = 42 AND status = 'PAID';
-- PostgreSQL：查看未授予的锁（等待链）
SELECT * FROM pg_locks WHERE NOT granted;典型使用场景
- 压测吞吐平顶：定位是哪条 SQL 或哪把锁卡住
- 慢接口解剖：对比有无索引的执行计划差异
- 上线前 SQL 评审：新查询先跑一次执行计划
- 连接池调优：池上限与数据库容量匹配
- 故障复盘：锁等待引发的级联雪崩
- 批量任务排查：大事务把在线请求一起堵住
现象与优先怀疑
| 现象 | 优先怀疑 | 验证方式 |
|---|---|---|
| QPS 平顶、库 CPU 饱和 | 热点 SQL 缺索引 | 执行计划与慢日志 TOP |
| 延迟锯齿波动 | 锁竞争或长事务 | 锁等待查询与事务时长 |
| 报连接耗尽 | 池上限太小或占用不释放 | 连接数与池监控 |
| IO 持续打满 | 全表扫描或排序落盘 | 执行计划与 IO 指标 |
先采集后优化：压测同步打开慢日志与指标面板，否则「优化前后」没有可信的对照数据。
索引不是越多越好：每个索引都在写路径上加成本，看读吞吐的同时也要盯写吞吐是否被拖慢。
应用与数据库混部会互相抢资源：指标失真、优化方向跑偏，压测尽量用独立实例。