连接池开启是默认行为，但必须显式确认
SQL Server 的
SqlConnection默认启用连接池（
Pooling=true），但很多团队在迁移或排查时误以为“没配就是没开”。不显式声明容易在部署环境因配置覆盖（如 config transform、环境变量注入）导致意外关闭池化。
务必在连接字符串中明确写出：
Server=...;Database=...;Pooling=true;Max Pool Size=100;
Pooling=false会彻底禁用池，每次
new SqlConnection()都走 TCP 握手+登录认证，高并发下秒变瓶颈 即使只写
Pooling=不带值，.NET 会按布尔解析规则转为
true，但语义模糊，建议写全 IIS 或容器重启后首次请求若池未预热，可能触发短暂延迟——这不是 bug，是池的懒加载机制
Max Pool Size 不是越大越好，需匹配服务器资源
Max Pool Size设太高，看似能扛住突发流量，实则把压力从应用层转移到数据库网卡、内存和连接数限制上。SQL Server 默认最大用户连接数是
32767，但操作系统层面的 socket 资源、线程调度、内存页分配都会先于 DB 层见顶。 常见误配：
Max Pool Size=500—— 若有 10 台应用服务器，理论最大连接数已达 5000，远超中小业务实际负载 合理起点：从
100开始压测，观察 SQL Server 的
sys.dm_exec_sessions中 active session 数与
wait_type（尤其
ASYNC_NETWORK_IO或
THREADPOOL） 注意：连接池中的“空闲连接”仍占用服务器端连接槽位，只是不执行命令；它们不会自动释放，除非超时（由
Connection Timeout控制握手阶段，而空闲连接回收靠
Connection Lifetime和内部 GC）
Min Pool Size 基本不用设，设了反而有害
Min Pool Size意图保持最小连接数常驻，但实际效果极差：它只在池首次初始化时起作用，且一旦连接因网络闪断、数据库重启等失效，池不会主动补足到最小值；更关键的是，它让连接长期空占资源，干扰连接泄漏诊断。 绝大多数场景下，
Min Pool Size=0（默认）最健康——冷启动慢一点，总比热着却拖垮 DB 强 唯一可考虑非零的例外：极低频但要求毫秒级响应的后台服务（如风控决策），且已确认 DB 端无连接风暴风险 如果真想“预热”，用代码主动执行一次
Open()+
Close()即可，比依赖
Min Pool Size可控得多
连接泄漏会让 Max Pool Size 形同虚设
池大小再大，也扛不住没
Dispose()或没
using的连接。泄漏表现不是报错，而是池中“活跃连接数”持续上涨，最终新请求卡在
Open()上，超时抛出
Timeout expired. The timeout period elapsed prior to obtaining a connection...。 必须确保所有
SqlConnection走
using块或显式
Dispose()，哪怕在
catch里也要包一层
finallyEF Core 用户注意：
DbContext的生命周期管理（Scoped/Transient）错误也会间接导致底层连接不归还 用 PerfMon 监控
.NET Data Provider for SqlServer\NumberOfPooledConnections和
NumberOfNonPooledConnections，前者长期 >80% 且缓慢爬升，基本就是泄漏信号 连接池参数本身很简单，难的是把它放进整个链路里看：上游的请求并发模型、中间件的超时设置、下游 SQL Server 的 max worker threads 和 memory grant 配置，缺一不可。调参前先确认你真正卡在哪一层。
