你改过数据库连接池的配置吗？大多数人的回答是“没有，用的默认值”。直到某天高峰期应用报错Connection is not available，你才打开配置文件，把maximumPoolSize从10改成50。问题解决了，但你不知道10和50的区别——你只是把数字调大了。
连接池的配置不是越大越好，也不是默认就行。设小了，请求排队等待；设大了，数据库被连接拖垮。
连接池的四大核心参数
无论使用HikariCP、Druid还是DBCP，都需要理解四个关键参数的含义和影响。
1. maximumPoolSize（最大连接数）
池子里最多能有多少个连接，包括正在用的和空闲的。这是最容易被误解的参数——新手容易设成100、200，甚至1000，觉得“连接越多并发越高”。实际上，过多的连接会导致频繁的上下文切换，反而拖慢性能。研究显示，每个应用实例10-30个连接通常就能兼顾稳定性与吞吐量。
2. minimumIdle（最小空闲连接数）
池子里最少要保留多少个“待命”连接，随时准备响应请求。HikariCP官方建议将minimumIdle设为与maximumPoolSize相同的值，避免流量波动时连接池反复扩容和缩容，产生不必要的性能开销。
3. connectionTimeout（连接等待超时）
当池子里的连接都被借走了，新的请求愿意等多久？默认值通常是30秒，建议调小到1-3秒。如果3秒都拿不到连接，说明数据库压力太大或发生了连接泄漏，应该让它“快速失败”（Fail Fast），避免请求线程长时间卡死。
4. maxLifetime（连接最大存活时间）
一个连接最长能活多久。这个值必须小于数据库服务端的wait_timeout（MySQL默认8小时），否则连接可能被数据库端主动断开，应用还以为是正常的，使用时就会报Pipe broken错误。建议设为30分钟（1800000毫秒）。
最大连接数到底设多少？
这是最核心的问题。PostgreSQL官方和HikariCP作者给出了一个经典公式：
连接数 = ((核心数 × 2) + 有效磁盘数)
对于4核CPU的数据库服务器，计算结果大约是9个连接。这个数字看起来很小，但4核CPU同一时刻确实只能处理4件事，给你1000个连接，996个都在排队等待，而CPU还要在这些线程之间频繁切换上下文，得不偿失。
如果数据库是8核+SSD，连接池大小建议在20-50之间。Navicat的官方建议也印证了这个范围：10到30个连接通常就能在稳定性与吞吐量之间取得最佳平衡。
MySQL的max_connections参数默认值是151，但这是数据库层面的总连接上限，不是单个应用连接池的值。多个应用实例共享同一个数据库时，需要将每个实例的连接数控制在合理范围内。例如，数据库可以处理100个连接，有5台应用服务器，每台的最大池大小就应设为20左右。
连接池调优检查清单
- 检查连接是否正确归还：使用
try-with-resources（Java）或using（C#）确保连接用完自动归还，避免连接泄漏耗尽池子。 - 检查SQL执行时间：SQL慢会让连接被长时间占用，释放不及时导致池满。慢查询日志是排查这个问题的起点。
- 启用连接验证：网络问题或数据库重启可能导致连接失效，配置
connection-test-query: SELECT 1可以让连接池自动检测并替换损坏的连接。 - 根据监控数据调整：监控
Active Connections和Idle Connections的变化趋势，评估现有池大小是否合理。
真实案例
某Spring Boot应用使用默认HikariCP配置（最大连接数10），高峰期偶尔报连接超时。排查发现应用部署了3个实例，总共最多30个连接。问题不在连接数，而在于某个接口执行了多次慢查询，每次耗时500ms，高峰期所有连接都被这些慢查询占满，新请求只能等待。最终，优化了SQL查询并加入缓存，连接池没改，问题解决了。有时候，问题不在池大小，而在连接被占用的时间。
最后一句
连接池的“最大连接数”不是越大越好——数据库的CPU核心数有限，过多的连接只会让线程频繁切换，反而降低性能。核心业务通常10-30个连接就够了，关键是要让连接被快速释放，而不是长期占用。如果配置调优后仍有问题，检查SQL执行时间和连接是否正确归还。