压测600没问题，上线后300就扛不住了，可能是什么原因？

压测 600 没问题，上线后 300 就扛不住了，可能是什么原因？

完整讲解（权威版）

最后更新：2026-10-28 · 基于第 1 次作答

L1 · 30 秒速记

结论：压测能过而生产扛不住，本质是压测环境与生产环境不同构——机器规格、数据量级、缓存状态、下游依赖至少一项失真，导致压测数字虚高。 关键词：环境差异 · 缓存命中率 · 数据量级 · 连接池 边界：压测只代表"理想流量模型"，容量评估必须用生产同构环境或流量回放，不能拿 demo 数据结论当生产结论。

L2 · 核心讲解

核心考点定位：考察能否把"压测通过但生产失败"从单个现象拆成"压测环境与生产环境的同构性"这一根因，并逐项举证；面试官想排除只归因于机器配置差或只归因于代码 bug 的单一归因。

机制链（≥3 环）：

1. 压测用小数据量 + demo 数据 → 查询全走缓存/小索引：压测时命中率高、扫描行数少，单请求 RT 极低，600 QPS 轻松扛住。
2. 生产数据量级大且冷启动 → 缓存未预热、命中率骤降：请求直达数据库，慢查询与回表放大，单请求 RT 上升，可用吞吐被压到 300 QPS 以下。
3. 生产长事务占满连接 → 连接池与线程池排队：数据库 max_connections 与连接池 maxTotal 成为新瓶颈，请求在 getConnection() 处阻塞，300 QPS 即出现堆积与超时。

证据锚点（去重 ≥6）：

• max_connections=151：MySQL 默认连接上限；连接被长事务占满后，应用拿不到连接。
• maxTotal / maxWaitMillis：HikariCP 等连接池参数；池满且等待超时即抛 ConnectionTimeoutException。
• slow_query_log + long_query_time=0.1：定位慢查询；重点看 Rows_examined 与 Rows_sent 比值是否扫描放大。
• innodb_buffer_pool_size：生产数据量增长后索引页放不进 Buffer Pool，命中率下降、回表变多。
• ThreadPoolExecutor：生产线程池被打满时，任务在队列排队，RT 与吞吐同时恶化。
• Full GC：生产堆内存压力大时，STW 拖慢全局吞吐，压测环境堆小且冷数据少不易触发。
• cache hit ratio：Redis 命中率；未预热时首波流量全部穿透到 DB。

对比与权衡：

常见误区：

1. 错误：压测能过就是代码没问题。→ 正确：压测只证明"该环境、该数据、该流量模型"下能过。→ 为什么：环境、数据量、缓存状态、下游依赖任一不同，结论即失效。
2. 错误：生产扛不住一定是机器配置差。→ 正确：配置只是一环，数据量级与缓存命中率往往是主因。→ 为什么：同配置下数据量增大，索引页放不进 Buffer Pool，扫描放大推高 RT。
3. 错误：加缓存就一定能扛住。→ 正确：缓存能扛读，但未预热、写热点、穿透仍会打到 DB。→ 为什么：未预热时缓存是空的，首波流量全穿透，反而放大 DB 压力。

适用边界：若压测环境与生产完全同构（同规格、同数据量、同流量、同下游 RT）仍扛不住，才怀疑应用代码；否则先解决环境失真。此结论适用于容量评估类问题，不适用于功能正确性类问题。

延伸追问（≥3）

1. 为什么压测用 demo 数据会让结论虚高？

• 要点：demo 数据量小、分布均匀，能全命中缓存、扫描行数少；生产数据分布不均会导致索引失效、回表放大。
• 追问落点：如何构造与生产分布一致的数据集（抽样 vs 全量克隆）？

1. 缓存未预热为什么会放大到数据库？

• 要点：冷启动命中率为 0，所有请求打到 DB；热点 key 重建又引发击穿与穿透。
• 追问落点：预热策略（定时预热/启动预热）与防击穿（互斥锁/逻辑过期）如何配合？

1. 连接池打满和数据库 max_connections 是什么关系？

• 要点：连接池耗尽通常先于 DB 上限；池大小、等待超时、DB max_connections 三者要联动设计。
• 追问落点：如何定位是连接池瓶颈还是 DB 瓶颈（看 getConnection() 超时 vs SHOW PROCESSLIST）？

面试者参考回答

【结论】 压测能过而生产扛不住，本质是压测环境与生产环境不同构：机器规格、数据量级、缓存状态、下游依赖至少一项失真，导致压测数字虚高。

【三点】 第一，先查环境差异：机器规格是否一致、是否有其他进程抢占 CPU/内存，用 top/free 对比；服务器上多个服务共享资源会抢 CPU 与 IO。第二，再查数据与缓存：生产数据量级大且冷启动未预热，缓存命中率低，请求直达数据库触发慢查询与回表放大，用 slow_query_log、Rows_examined、Redis hit ratio 佐证。第三，最后查资源瓶颈：连接池 maxTotal 与 maxWaitMillis、数据库 max_connections、线程池队列是否被打满，长事务占连接导致 300 QPS 就排队超时。处置按根因分类：预热缓存、优化慢 SQL、加索引、调连接池与线程池。

【边界】 若压测环境与生产完全同构（同规格、同数据量、同流量、同下游 RT）仍扛不住，才怀疑应用代码；否则先解决环境失真。任何容量结论都要声明适用的数据量与流量模型，不能拿 demo 数据结论当生产结论。

面试记录 2026-10-28（第 1 次）

题目：压测600没问题，上线后300就扛不住了，可能是什么原因？

难度：low

标签：practice/performance, practice/debug, general/knowledge

评分：⭐⭐⭐☆☆（3/5）

我的回答

压测600没问题上线 300 就不行,首先是环境问题,压测的环境是否是真实环境?数据量级是否一直?服务规格是否一致,部署服务的服务器是否有其他资源在使用?使用的缓存是否存在不同?数据库数据量大的情况下,请求可能会因为慢查询而导致 rt 增加;另外是否缓存没有预热,没有能走缓存,都直接访问到了数据库,由于压测样本问题,使用的数据可能是 demo 数据,导致都能命中缓存,没有压到数据库,导致两个环境上的状态不一;还有是如果服务器上有其他开启的服务,是否抢占了服务器的资源导致 cpu 被占用导致吞吐量降低;还可能是其他接口占用了过多资源导致服务 gc,影响吞吐,具体需要逐一进行排查;

点评

评分：⭐⭐⭐☆☆（3/5）

优点：抓住"压测环境 vs 生产环境差异"核心矛盾、缓存未预热/压测样本命中缓存判断准、有逐一排查意识。

不足：没提连接数/线程池维度（压测 600 挂生产 300 挂常见根因是生产连接池占满、慢 SQL 放大、依赖第三方变慢）、没提依赖链差异、没提数据分布索引失效。

补充：对照 4 类差异——①机器规格/资源占用 ②数据量级与索引分布 ③缓存预热与命中率 ④下游依赖 RT；再查线程池、GC、连接池占用。

完整讲解见上方「完整讲解（权威版）」