上周和一个做后端开发的朋友喝酒，他吐槽说最近被线上数据库连接池的问题折磨得够呛。项目上线后，高峰期时不时报连接超时，他一开始以为是连接数太少，于是一口气把连接池从 20 调到 200，结果反而把数据库搞崩了，半夜三点爬起来回滚配置。这事儿听着耳熟，几乎每个搞过后端的人都在这上面栽过跟头。数据库连接池到底配多少合适，这个问题看似简单，却牵涉的东西远比想象中复杂。
很多人第一反应是，连接池配得越大越好，毕竟并发请求多嘛，多开几个连接总没错。但现实往往打脸：连接数一旦超过某个阈值，数据库的响应时间反而会飙升。原因在于，数据库本身是有限资源，每个连接都要占用内存、CPU 上下文切换的开销。比如 PostgreSQL，每个空闲连接大概吃掉几兆内存，1000 个连接就是几个 GB，还没算上活跃连接跑 SQL 时的资源消耗。MySQL 也类似，innodbbufferpoolsize 本身就有限，连接数多了，锁竞争、线程调度全部挤在一起，性能直线下降。更隐蔽的是，应用服务器和数据库之间的网络带宽、文件句柄数，这些都是硬约束，不能随意打开。
那到底怎么估算合适的连接数呢？有个经典的公式是“连接数 = 核心数 × 2 + 有效磁盘数”。这个公式来自 HikariCP 的官方文档，算是行业里的一个经验锚点。但实际业务并不这么单一：如果是 IO 密集型任务，比如大量读写磁盘，连接数可以适当放大；如果是 CPU 密集型，比如复杂计算、大量排序，连接数反而要压下来。另一个关键因素是请求的平均响应时间。假设接口平均耗时 50 毫秒，那么一个连接每秒能处理 20 个请求。如果业务峰值是每秒 2000 个请求，理论上 100 个连接就够了。但别忘了，数据库还有慢查询、锁等待等拖后腿的因素，实际需要的连接数往往要打个折扣。
很多团队喜欢把连接池配成一个固定的静态值，上线后就不管了。但流量是有波动的，双十一和平时能一样吗？更合理的做法是引入动态调整机制。比如使用 HikariCP 的 minimumIdle 和 maximumPoolSize，让连接池在空闲时缩到最小，峰值时自动扩容。但动态调整也有坑：扩容太慢会导致请求排队，缩容太快又会频繁创建销毁连接，反而增加开销。我见过一个团队直接在代码里写死连接池大小，然后依赖限流来保护数据库，效果反而比盲目增大连接池要好。关键是要弄清楚瓶颈到底在数据库，还是在应用层。
还有一个容易被忽略的点，连接池的大小应该和线程池的大小联动。很多应用使用 Tomcat 或 Jetty 的线程池，每个线程处理一个请求。如果线程池有 200 个线程，而连接池只有 20 个，就意味着 180 个线程在排队等数据库连接，这显然不合理。反过来，线程池只有 50 个，连接池配 200 个，大部分连接都是空闲的，白占资源。理想的比例是线程池和连接池差不多，或者连接池略小于线程池，让线程稍微等一等连接，而不是让连接空转。这个细节，很多架构师都没有意识到。
再说说数据库端的配置。有些 DBA 为了省事，直接把 maxconnections 设成几千，觉得反正连接池会控制。但连接池只是应用层的控制，如果多个应用实例同时连同一个数据库，每个实例的连接池都配了 100，10 个实例就是 1000 个连接，数据库端的 max_connections 只有 500，就会直接翻车。所以连接池的配置必须和数据库端的限制对齐，最好在中间层加一个全局监控，比如用 ProxySQL 或 PgBouncer 这类中间件来做连接复用。我曾在一个高并发场景下，用 PgBouncer 把上千个应用连接压缩到几十个数据库连接，性能提升了约 30%，因为减少了数据库端的上下文切换。
其实说到底，连接池配多少合适，没有标准答案。不同的业务模型、不同的数据库引擎、不同的硬件环境，最优值千差万别。但有一条通用原则：先压测，再调优，不能靠猜。用 JMeter 或 wrk 模拟线上流量，配合慢查询日志和数据库监控，一步步找到临界点。比如先把连接池设成 10，逐渐加到 20、30，观察响应时间和数据库 CPU、IO 的变化，直到出现拐点，那个值就是你的最佳配置。过程可能枯燥，但比线上出问题再救火要省心得多。
回到开头那个朋友的故事，他后来花了两个周末，把业务接口的平均响应时间从 80 毫秒优化到 15 毫秒，然后把连接池从 200 降到 30，数据库压力反而降了一半。你看，连接池的配置问题往往是系统性的问题。优化查询、减少锁竞争、合理规划索引，比一味堆连接数要有效得多。如果你现在正被连接池困扰，不妨先问问自己：是不是业务本身就有问题，连接池只是在替你背锅？
