公司内部的订单系统突然变慢，用户投诉不断。运维团队查了一圈，CPU、内存、网络都没问题，最后发现是数据库连接池配得太小。高峰期请求涌进来，连接不够用，大量线程卡在等待连接上，响应时间从200毫秒飙到几秒。
连接数设太小：排队成常态
有个项目把数据库连接池最大连接数设成10，想着“省资源”。结果一到促销活动，几百个并发请求全挤在这10个连接上。就像早高峰只开一条安检通道，后面排长队，系统响应越来越慢。日志里全是“获取连接超时”，其实不是数据库扛不住，是应用自己把自己堵死了。
连接数设太大：资源反被拖垮
反过来也常见。有人觉得“多开点总没错”，把连接池设成500。一台应用服务器起5个实例，每个实例500，光连接就占了2500个。数据库本身能支撑的连接数有限，一下子被打满，甚至触发内存溢出。更糟的是，连接太多导致上下文切换频繁，CPU空耗在调度上，真正干活的时间反而少了。
空闲连接不回收：浪费还在继续
有些服务白天忙，夜里几乎没流量。但连接池配置里最小空闲连接设成50，哪怕半夜也维持这么多连接。数据库端看着一堆空连接占着内存和句柄，资源白白浪费。合理做法是设置合理的空闲超时时间，比如30分钟没用就释放。
一个典型的 JDBC 连接池配置示例
<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource">
<property name="jdbcUrl" value="jdbc:mysql://localhost:3306/order_db" />
<property name="username" value="root" />
<property name="password" value="123456" />
<property name="maximumPoolSize" value="20" />
<property name="minimumIdle" value="5" />
<property name="idleTimeout" value="300000" /> <!-- 5分钟 -->
<property name="connectionTimeout" value="30000" /> <!-- 30秒 -->
</bean>这个配置兼顾了性能和资源控制。最大20个连接防过载，最小保持5个避免频繁创建，空闲超时5分钟自动释放。比起拍脑袋设数字，更靠谱的做法是根据平均响应时间、并发量估算：比如每秒100请求，平均处理耗时100毫秒，理论上需要10个并行连接就够了，再留点余量到15~20，基本就稳了。
连接池不是设完就高枕无忧。业务增长、流量模式变化，都得回头看看配置还合不合适。定期看监控，关注“等待连接数”、“活跃连接数”这些指标，比出问题再救火强得多。