背景
接口一压测，QPS 上不去，很多团队第一反应就是查数据库。这当然没问题，但如果每次都只盯着 SQL，很容易漏掉一些同样常见的瓶颈。
我之前做过几次压测复盘，发现真正影响 QPS 的因素经常不止一个，而且往往有一些很容易被忽略。
1. 线程池配置不合理
如果接口本身依赖外部服务或者有一定阻塞时间，线程池配置就会直接影响吞吐。
比较典型的问题有：
- 工作线程太少
- 队列太长，吞掉了短期抖动
- 拒绝策略没有暴露出真实压力
很多时候不是系统“扛不住”，而是请求在内部排队太久，导致看起来 QPS 上不去。
2. 连接池成为隐性瓶颈
数据库连接池、HTTP 连接池、Redis 连接池，只要有一个配置偏保守，都可能限制整体吞吐。
这种问题的特点是：
- CPU 还没打满
- 数据库本身也没到极限
- 但请求吞吐始终上不去
本质上是业务线程在等连接，而不是在真正执行。
3. 外部依赖的波动被低估了
压测并不只是在测你自己。如果请求链路里有 RPC、HTTP、缓存回源、消息确认等操作，任何一个外部环节抖一下，整体吞吐都会受影响。
尤其是高并发下，哪怕单次波动只多几十毫秒，累计起来也会很明显。
4. 日志和监控本身带来了额外开销
这个点经常被忽略。排查性能问题时，大家喜欢把日志打得很全，但在高并发压测下，频繁的同步日志、复杂的埋点和过重的链路追踪都有可能拖慢接口。
所以压测环境里最好区分：
- 必要监控
- 调试用额外日志
否则你可能测到的是“排查系统本身”的性能上限。
5. 压测脚本和流量模型不够真实
还有一种情况，不是系统扛不住，而是压测方式本身不合理。比如：
- 所有请求都打到同一个热点数据
- 用户登录态复用方式不符合真实场景
- 突发流量模型和线上完全不同
这种情况下，得出的瓶颈结论也容易偏。
总结
QPS 上不去，数据库当然值得查，但不应该只查数据库。线程池、连接池、外部依赖、日志开销、压测模型，这些都可能成为真正瓶颈。
我越来越觉得，性能排查里最怕的不是系统慢，而是还没把瓶颈范围看完整就急着下结论。
