数据库连接池：不是越大越好，瓶颈经常在等待队列而不是连接数

现象：
一个 API 服务 P99 突然升高，数据库 CPU 不高，慢查询日志也没有明显慢 SQL。排查发现连接池配置 max=50，高峰期大量请求在等连接，等待时间计入接口耗时。第一反应是把连接池调大，调到 200 后 P99 反而更差。

原因拆解：
数据库连接是有限资源，每个连接占内存和文件描述符，过多连接会导致上下文切换和锁竞争。连接池大小应该和数据库能有效处理的并发量匹配，而不是和 API 的并发请求数匹配。API 并发高但单请求数据库操作很短时，连接池不需要很大，需要的是快速释放和合理排队。

调优顺序：
第一，看连接等待时间，而不是只看连接数。第二，看事务持有多久，长事务会占住连接，导致池子被少数请求耗尽。第三，看是否有连接泄漏，比如异常路径没归还。第四，才是调 max 和 min，并且配合超时和排队上限。

一个实用公式参考：
连接数上限 roughly 等于数据库 CPU 核数乘以一个系数，再根据 I/O 等待调整。但这不是硬公式，要用压测验证。更稳的做法是给获取连接设超时，快速失败而不是无限排队；给事务设超时，避免长事务拖垮池子；监控等待队列长度和获取耗时。

复盘：
连接池不是“越大越能扛”，它是数据库前面的缓冲阀。调大之前先问：连接是被谁占住的、占多久、有没有泄漏。很多 P99 问题不是池子太小，是连接被慢事务或泄漏卡住了