连接池大小怎么定？「CPU 核数的 10 倍」是经验值还是陷阱？

【背景】

在高并发系统中，连接池的大小一直是一个常见的调优话题。很多团队会参考「连接池大小 = CPU 核数 × 10」这样的经验值。然而，实际场景中，这个经验是否适用？是否会导致性能抖动、资源浪费甚至影响系统稳定性？

【常见分歧】

1. 经验值派：认为「连接池越大越好」，能提升吞吐，降低延迟，尤其在数据库连接成本高的场景。

2. 动态调整派：主张根据负载、资源使用情况动态调整连接池大小，避免资源浪费。

3. 安全边界派：认为连接池应设置上限，防止资源耗尽，尤其是在共享资源的场景。

【我的倾向】

我认为，连接池的大小不应简单地依赖「CPU 核数 × 10」这样的经验值。这可能是一种误导，甚至会带来性能抖动。正确的做法是：

• 通过监控和日志分析，了解实际的连接使用模式。
• 在资源允许的范围内，设置合理的最大连接数。
• 配合连接池的最小空闲连接数、最大等待时间等参数，实现动态平衡。

【想听大家的场景】

我很好奇，大家在实际工作中是如何处理连接池大小的？有没有遇到过因为连接池设置不当导致的性能问题？在什么场景下，你们会采用「CPU 核数 × 10」的经验？

欢迎分享你的经验和观点！