凌晨三点，你的告警手机响了。CPU炸了，接口响应时间飙到10秒，用户在群里疯狂刷屏。你SSH连上服务器，top一看，Java进程占用99%的CPU，GC日志惨不忍睹。

你开始疯狂Google："Java应用CPU占用高怎么办"。

然后你发现一篇文章说可能是数据库连接池配置有问题。你将信将疑，打开配置文件，看到的是：

maxPoolSize: 100
minIdle: 10
connectionTimeout: 30000

等等，100个连接？你的应用部署在2核4G的机器上，数据库服务器也是个小水管，你确定这是连接池而不是连接炸弹？

这篇文章，我们来聊聊数据库连接池——这个几乎每个后端应用都在用，但大多数人压根没配对的东西。

连接池是什么？为什么你需要它

在你愤怒地划走之前，先确认一下你是否真的理解连接池。

数据库连接不是你家宽带，不是说"连上就一直保持着"就行。每次建立TCP连接、数据库认证、握手、分配资源，这一套下来可能需要20-100毫秒。如果你每个请求都新建连接，高并发下光是建连接就能让你死得很难看。

连接池的核心思想很简单：预建立一批连接，用完了归还池里而不是关闭，下次直接拿来用。这和线程池、协程池的思路一脉相承。

但问题来了：预建立多少连接是合适的？

那个100连接的默认值，是谁给你的勇气

HikariCP的默认maxPoolSize是10。Druid的默认是20。c3p0的默认是3。

所以当你随手配了100的时候，有想过这些数字是怎么来的吗？

数据库连接是有成本的。每个连接都要占用服务端资源——内存、文件描述符、进程/线程结构。更重要的是，每个连接都对应着数据库服务端的一个工作线程或进程。你创建100个连接，MySQL可能就为你分配了100个线程。

当你的机器只有4核8G，你配了100连接会发生什么？

想象一下：100个人同时涌进一个只有4个窗口的银行。这些人不是在办理业务，他们只是在排队等窗口。这意味着：

• 数据库端：100个线程同时等待查询执行，内存和CPU被疯狂消耗
• 你的应用端：连接等待时间变长，请求堆积，线程阻塞
• 结果：系统整体吞吐量反而下降，你加了连接数却让系统变慢了

这不是我在吓你，这是实打实的资源争抢。

连接池大小的正确计算方式

那么问题来了，到底配多少合适？

有个经典的公式：连接数 = 核心数 * 2 + 磁盘 spindle 数。这个公式是PostgreSQL官方文档里给出的建议值。

但说实话，这个公式对于现代SSD来说已经不太适用了。更重要的是，这个公式只是给出了理论上限，具体还得看你的业务。

我个人的经验是：从最小值开始，逐步压测调优。

具体步骤：

1. 先用默认值（10左右）跑压测，记录基准QPS和延迟
2. 逐步增加连接数，每次增加5-10个
3. 观察两个指标：数据库CPU使用率和应用端平均响应时间
4. 当数据库CPU超过70%，或者响应时间开始上升，就是你的最优连接数

有个简单的判断方法：如果你的连接数增加但吞吐量不增加，说明连接已经够了，再多就是浪费。

那些年我踩过的连接池坑

说几个我见过的奇葩配置，都是真实案例，名字我匿了但教训是真的。

案例一：minIdle等于maxPoolSize

一个同事配了maxPoolSize=50，minIdle=50。他的想法是："反正要用50个，干嘛不一开始就建好？"

结果：应用启动极慢，因为要等50个连接全部建立完成。更要命的是，凌晨业务低峰期，数据库端仍然保持着50个活跃连接，浪费了大量资源。而他的DBA每天早上都在问我为什么数据库连接数这么高。

教训：minIdle应该远小于maxPoolSize，除非你有明确的理由需要保持最小连接数。

案例二：connectionTimeout=0

有个新手同学配置了connectionTimeout=0，意思是"无限等待"。他以为这是为了让连接"永远不超时"。

结果：一次数据库出现短暂网络抖动，所有请求都卡在获取连接上，永远等不到。应用彻底死锁，只能重启。

教训：connectionTimeout必须设置，而且不能太大。建议3000-10000毫秒。超时时间是你能承受的等待上限，而不是"永远等着"。

案例三：忽视validationQuery

有些团队为了"性能"，把连接池的连接检测关了。他们的理由是："我们数据库很稳，不需要检测。"

结果：一次数据库主从切换，某些应用获取到的是已经断开的连接。请求直接报错，用户看到的是莫名其妙的500错误。

教训：连接检测不是可选项，是必选项。你可以用validationQuery，也可以用connectionTestQuery，具体看数据库类型。HikariCP还有个更好的方案是使用TCP层面的连接检测（enableAutoRecovery=true）。

连接池的健康，不只是配置问题

配置只是基础，更重要的是监控。

你的连接池指标，应该能看到：

• activeConnections：当前活跃的连接数
• idleConnections：空闲连接数
• threadsAwaitingConnection：等待连接的线程数
• connectionsCreated/second：每秒新建连接数
• connectionsTimeout/second：每秒连接超时数

如果你没有这些监控，赶紧加上。如果threadsAwaitingConnection经常大于0，或者connectionsTimeout每秒都在发生，你就是在慢性自杀。

我见过最离谱的是一个团队，他们的HikariCP监控显示平均每分钟有300多次连接超时，但他们完全不知道，因为压根没配监控。

说了这么多，到底怎么配

给个参考值，这是我在中小型应用（4-16核机器，单实例QPS 1000以内）的经验：

# HikariCP示例配置
maximumPoolSize: 20-30
minimumIdle: 5-10
connectionTimeout: 10000
idleTimeout: 600000
maxLifetime: 1800000
connectionTestQuery: SELECT 1

注意：这是参考值，不是标准答案。你的应用有你的情况，请务必结合实际负载测试结果调整。

还有一点：不要只看应用端配置，数据库端的max_connections也要关注。如果你的应用有10个实例，每个实例50连接，那数据库至少需要500+的max_connections预留。我见过有人的应用连不上数据库，最后发现是数据库的max_connections只有100，而他们的连接池配置加起来远超这个数。

总结

连接池配置是个技术活，不是玄学。核心要点：

1. 连接数不是越大越好，和你的硬件资源匹配
2. 从保守值开始，通过压测找到最优
3. timeout必须设置，不要设成无限
4. 连接检测必须开启
5. 监控比配置更重要，不知道现状就没法优化

下次你的应用出问题了，别急着加配置。先看看连接池有没有被正确配置，是不是在好好工作。

毕竟，你花大价钱买的数据库，可能就毁在一个随手配的"100连接"上。

你说冤不冤？