为什么连接数不是越多越好？
很多开发者遇到数据库响应变慢时，第一反应是调大连接池的最大连接数，认为“更多连接 = 更高并发”。但实际效果往往适得其反：数据库 CPU 飙升、响应时间反而更长。这背后的原因可以用排队论解释。
数据库连接的本质：排队系统
数据库处理查询可以看作一个排队系统：
- 服务台：数据库的工作线程（或 CPU 核心）
- 顾客：客户端请求（SQL 查询）
- 队列：连接池中的等待队列
当并发请求数超过服务台的处理能力时，请求会在队列中等待。根据排队论中的 利特尔法则（Little's Law）：
L = λ × W
其中 L 是系统中的平均请求数，λ 是请求到达速率，W 是平均等待时间。当连接数超过数据库实际能并行处理的线程数时，每个请求的等待时间 W 会非线性增长，导致整体吞吐量下降。
连接池容量过大的三个代价
- 上下文切换开销：数据库为每个连接分配线程或协程，连接数过多导致 CPU 频繁切换，有效计算时间减少。
- 内存与锁竞争：每个连接占用内存，且并发事务增加会加剧锁竞争、死锁概率。
- 缓存命中率下降：过多并发查询会挤占数据库缓冲池，降低缓存效率。
如何计算合理上限？
一个实用的经验公式来自 PostgreSQL 社区（同样适用于 MySQL 等）：
最大连接数 ≈ CPU 核心数 × 2 + 有效磁盘数
例如，4 核 CPU + 1 块 SSD，建议最大连接数约为 9~10。对于 SSD，有效磁盘数可视为 1；对于多块机械硬盘，可适当增加。
更严谨的方法是通过压测找到拐点：
- 固定请求速率，逐步增加连接池大小（如 5、10、20、50）。
- 记录每个连接数下的 QPS 和平均响应时间。
- 找到 QPS 不再上升、响应时间开始陡增的临界点，取该点以下的值。
连接池配置建议
- 最小连接数：设为预期平均并发量，避免频繁创建销毁连接。
- 最大连接数：参考上述公式，并结合压测结果，通常不超过 CPU 核心数的 2~4 倍。
- 连接超时：设置合理的获取连接超时（如 3~5 秒），避免请求无限等待。
- 空闲检测：定期验证空闲连接有效性，防止使用已断开的连接。
总结
数据库连接数不是性能的“油门”，而是需要精细调节的“阀门”。盲目调大连接数会引入排队延迟、上下文切换和资源竞争，反而降低吞吐量。合理的做法是：先估算，再压测，找到拐点，留出余量。记住，让数据库保持“忙碌但不拥挤”的状态，才是最优解。