高请求应用中设置Min Pool Size是否会导致存储过程响应时间变长？

首先明确：设置Min Pool Size本身不会直接导致存储过程响应时间变长，但需要结合实际场景分析潜在的间接影响：

1. 连接池的核心作用 #

连接池的本质是复用已建立的数据库连接，避免频繁创建、销毁连接带来的性能开销。Min Pool Size指定的是连接池会长期保持的最小空闲连接数，Max Pool Size则是连接池允许的最大连接数量。

2. 与存储过程执行的直接关联 #

存储过程的执行速度，主要由SQL逻辑复杂度、数据库的CPU/内存/IO资源、锁等待情况等因素决定，和连接池的最小空闲数没有直接关系——只要应用能正常获取到可用连接，存储过程的执行阶段不会受该参数影响。

3. 需要关注的间接风险 #

• 如果你设置了较大的Min Pool Size（比如200），这些连接会长期被你的应用占用。如果其他共用该数据库的应用也有较高连接需求，当整体连接数接近数据库的最大连接数限制时，其他应用可能会出现等待获取连接的情况，间接让它们的存储过程调用看起来变慢（本质是等待连接的时间变长，而非存储过程执行本身变慢）。
• 若你的应用实际并发请求量远低于200，维持200个空闲连接会浪费数据库的内存资源，但这也不会直接导致存储过程执行变慢，只是不必要的资源消耗。

4. 针对你的场景的建议 #

• 先确认数据库的最大连接数配置（比如SQL Server默认是32767，但实际可能有调整），计算所有共用该数据库的应用的连接池Max Pool Size总和，避免超过数据库上限。
• 不建议直接设置过大的Min Pool Size，先监控当前应用的连接使用情况：比如查看高峰时期的连接数峰值，再调整Min/Max Pool Size，让Min Pool Size接近平时的空闲连接需求即可。
• 原连接字符串中的MultipleActiveResultSets=True（MARS）如果你的应用不需要在同一个连接上同时执行多个结果集，可考虑关闭，减少潜在的连接资源占用。
• 优先排查代码端是否存在连接泄漏：比如是否有打开连接后未及时释放的情况，这才是高请求量下连接池耗尽、导致请求变慢的常见原因。

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