标准答案
- 池太小会让请求在应用侧等待，池太大会增加数据库内存、上下文切换、锁竞争和 I/O 压力，可能让吞吐在拐点后下降。
- 总连接预算要按实例数、进程/worker 数、后台任务、管理连接和故障扩容后的最大实例数计算，并预留运维空间。
- 池应设置获取超时、最大生命周期、空闲回收、健康检查和连接重建退避；数据库重启或网络断开时要丢弃坏连接。
- 池满时要区分查询慢、连接泄漏、下游等待和并发过高，不能只把池上限调大来隐藏排队。
- 事务池和会话池的语义不同；临时表、session GUC、prepared statement、通知、游标和 advisory lock 都需要按池化模式测试。
题目解析
数据库连接是有限资源，但“连接多”不等于“并发能力强”。当查询已经被 CPU、I/O 或锁限制时，更多连接只会把等待从数据库内部转移到更大的队列。
连接池大小必须乘上部署规模计算：每个实例配置 20 个连接，扩容到 30 个实例后就是 600 个数据库会话。还要为管理、迁移和故障切换留出预算。
正确的池化策略应让过载尽早、可解释地发生，例如在应用侧获取连接超时并返回可重试错误，而不是让所有请求无限等待。
常见误区
- 误区：每个实例配置几十或几百个连接。改正：先算全局连接预算，再根据查询耗时、CPU 和锁测试有效并发。
- 误区：只看 max_connections。改正：还要扣除管理、复制、监控和故障扩容所需连接。
- 误区：连接池满就增加上限。改正：先判断泄漏、慢查询、下游等待和重试放大，否则只会扩大数据库故障。