把连接池上限从 20 调到 50，早高峰超时反而更多了，连接到底被谁占着？

结论先说：早高峰接口批量超时、日志出现 Connection is not available，常见原因不是池子上限开小，而是连接被慢查询、长事务、事务里调外部接口或漏归还占住，池子只是先报警的地方。按 2026 年项目交付经验，先看活跃连接曲线和获取连接等待分位值，再决定调池还是治 SQL；单向上调池上限，容易把排队压力原样推到数据库的 max_connections 上，出现调得越大反而更糟的现象。

连接池报错到底在说什么

连接池是应用启动时先建好一批数据库连接、用完归还的复用机制，目的是省掉频繁握手和认证的开销。池子被占满时，请求不会立刻失败，而是进入等待队列，等过设定时间才抛出获取连接超时，日志里常见 Connection is not available, request timed out after N 毫秒。这句话只说明这一时刻没拿到连接，并不直接等于某条 SQL 执行慢。

两类根因的处置方向相反：容量不足是并发请求长期大于池上限，活跃连接贴着上限走，等待时间随并发同步抬升；占用则是连接被某类操作长时间握住，活跃连接数看着不高，周转却很慢。方向判错，调池会把应用层的排队放大成数据库层的问题。

• 活跃连接数、空闲连接数、等待获取连接的线程数，三个数放一起看，才能分清是池满还是连接被闲占。
• 获取连接耗时的 P95/P99，只看平均值容易漏掉排队尖刺。
• 超时分布，是否集中在整点任务、报表导出、批量导入前后。
• 数据库端的 Threads_connected、慢查询数量与长事务列表。

第一轮定位：三看一算

这套顺序在两三个小时到半天内通常能出初步结论，不必等完整监控大屏。它的作用是用低成本证据先排除方向性错误，再决定改配置还是改代码。

1. 看曲线：取高峰前 30~60 分钟到高峰结束的连接曲线，与请求量放在同一时间轴，看是请求涨连接跟着涨，还是请求没变连接先满。
2. 看等待：拉获取连接耗时的分位值。P95 从几十毫秒涨到几秒，说明请求在排队；获取很快而执行慢，问题落在 SQL 侧。
3. 看占用：查数据库慢查询和长事务，重点看事务里有没有 HTTP 调用、文件处理、循环查询；应用侧看连接持有时间偏长的几条链路。
4. 算上限：实例数乘以每实例池上限，要落在数据库 max_connections 的 70%~80% 以内，把余量留给运维、批处理和故障切换。

算上限时别只按当前实例数，要按扩容后的数量算；看曲线要和发版时间、定时任务对齐，否则容易把整点报表当成代码退化。

调池、治 SQL、读写分离的成本对比

三条路线不互斥，但顺序有讲究：先用低成本手段压短连接占用时间，再考虑扩容容量。以下是 2026 年常见交付节奏下的经验区间，具体随项目规模浮动。

• 调大连接池：配置类改动，通常半天到一天改完，验证要覆盖 3~5 个工作日高峰。适合实例少、数据库余量充足、确认是并发容量不足；代价是数据库连接数和内存上升，池子总量一旦越过 max_connections 的余量，等待就被转移到数据库端。
• 治慢 SQL 与缩短事务：改动集中在少数链路，常见 1~3 周含回归。适合活跃连接不高但等待长的场景；代价是要改代码并回归，常见坑是只加索引不看执行计划。
• 读写分离或加缓存层：常见 3~6 周，还要处理主从延迟与缓存一致性。适合读多写少、单库连接长期吃紧；代价是链路变长、排查成本上升。

粗判口径：高峰活跃连接只到池上限六成左右，先别扩池；长期在九成上下且等待分位值同步抬升，再评估扩池与扩容数据库。

交付现场：池子调大后反而更糟的一次

一个多实例后台，8 个应用实例、每实例池上限 20，数据库 max_connections 在几百的量级，甲方希望先把池子调大顶过早高峰，扩库要排采购周期。做法是先抓高峰前 30 分钟的慢查询和长事务，发现一个报表统计在事务里跑了十几秒，另有一条链路在事务内调外部接口；把统计挪到离线任务、事务拆短、外部调用移出事务后，池上限回调到每实例 12~16 的经验区间（常见区间，不是标准值）。结果早高峰的获取连接超时基本消失，代价是约两天改代码与回归。若当时直接把每实例加到 50，8 个实例就是 400，再叠加运维、批处理和其他系统的连接，数据库余量会被吃光，故障会从应用层挪到数据库层。

适用与不适用边界

适合：应用多实例部署、数据库连接数有明确上限、超时集中在早高峰或整点批量任务、日志能拿到获取连接等待时间。这类场景按三看一算定位，通常一两天内能分出是容量还是占用。

不适用：数据库连接长期只用到上限三四成、超时来自单条 SQL 本身执行慢，重点不在池子；按请求计费的短连接形态，池配置逻辑与常驻服务不同，要按平台规范核对；偶发一两次超时且无业务影响，先加监控观察更合适。

边界句：连接池调优管的是连接供给与占用时间，管不了慢查询本身的执行成本；SQL 耗时降不下来，池子再大也只是把应用排队换成数据库排队。

改完怎么算合格

验收别只看没再报错，建议连续观察 3~5 个工作日，覆盖早高峰和整点任务。

• 高峰活跃连接不超过池上限的 70%~80%，且不再长时间贴近上限。
• 获取连接等待 P95 落在几十毫秒到两百毫秒的经验区间，P99 不出现秒级尖刺。
• 获取连接超时降到每天个位数或零，且没有集中出现在固定时刻。
• 数据库端连接数留出 20%~30% 余量，慢查询数量同步下降。
• 持有时间偏长的几条链路有明确上限，事务里不再有外部调用。

常见问题

连接池开得越大，接口是不是越不容易超时？

不是。池子总量超过数据库能承受的连接数，等待会转移到数据库端；常见做法是按实例数和 max_connections 反算，而不是单实例一味调大。

Connection is not available 和 SQL 执行超时是一回事吗？

不是。前者发生在获取连接阶段，后者是已经拿到连接、SQL 跑太久；看报错堆栈落在哪一层，能省下不少排查时间。

压测环境正常，上线早高峰还是超时，差在哪？

压测多是固定并发和少量数据，线上是突发流量加真实数据分布，慢查询、锁等待和整点任务叠加后，连接占用时间会明显变长。

用了云数据库或数据库代理，应用侧还要配连接池吗？

要配。代理收敛的是后端连接，应用侧的池上限、等待超时和泄漏检查仍要设置，两边上限要一起核算，扩容后才不会互相顶。

如果正卡在早高峰超时，建议先取一段高峰连接曲线和获取连接等待分位值，再对照慢查询与长事务，通常一两天能分出是容量还是占用。以上判断适用于有明确数据库连接上限、多实例部署的常驻服务；单机小流量或短连接形态不必照搬，按平台规范核对更稳妥。