数据库连接达上限时连接池大小小于线程*worker数的可行性咨询

1. 连接池大小小于线程数*worker数的业界看法 #

• 这是非常成熟的主流实践，几乎所有互联网公司的OLTP业务都采用这个配置逻辑，不存在方案合理性问题
• 核心底层逻辑是：数据库的有效并发处理能力远低于应用侧的线程总量，绝大多数应用线程的工作时间里，只有10%~30%是在执行数据库操作，剩余时间都在处理业务逻辑、调用其他服务/缓存IO，完全不需要为每个线程绑定独立的数据库连接
• 反过来如果真的把连接池配到等于线程数*worker数，反而会导致数据库侧连接过多，引发上下文切换开销暴涨、锁竞争加剧、Buffer Pool命中率下降等问题，最终拉低整个数据库的吞吐上限

2. 不扩容数据库时，更小连接池能否满足业务需求 #

• 完全可以，甚至大部分情况下缩小连接池反而会提升数据库的整体吞吐表现
• 只要满足两个前提即可：第一，连接池等待获取连接的耗时符合业务接口的SLA要求；第二，连接池的总承载能力（连接数 * 每秒单连接可执行SQL数）高于业务峰值SQL请求量
• 少量线程等待连接属于正常现象，远好于连接数开太大把数据库打垮导致的全量业务不可用

3. 连接检出超时概率与合理的线程连接比 #

• 连接检出超时的概率没有通用固定值，完全取决于你的业务场景特征：核心影响因素包括单SQL平均执行时长、线程持有数据库连接的时间占比、业务峰值QPS。如果业务慢SQL多、持有连接时间长，哪怕1:1的比例也可能频繁超时，如果SQL都很小、持有连接时间短，10:1的比例也可能几乎没有超时
• 对于常规OLTP业务（单SQL平均执行时长<20ms，线程持有连接的时间占比<20%），业界通用的可接受比例范围是3:1 ~ 10:1
• 建议不要只卡比例数值，核心观测两个指标即可：一是连接池检出平均耗时占接口总耗时的比例低于5%，二是超时请求占比低于万分之一，只要满足这两个指标，不管比例多少都是合理的。可以搭配设置合理的connection-timeout参数，超时后直接走业务降级逻辑，避免请求堆积

内容的提问来源于stack exchange，提问作者l33z3r