SQL Server连接池默认启用但须显式声明Pooling=true，避免配置覆盖导致意外关闭；Max Pool Size宜从100起压测，Min Pool Size=0更健康；连接泄漏会使池失效，务必用using或Dispose确保归还。

连接池开启是默认行为，但必须显式确认

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 里也要包一层 finally
• EF Core 用户注意：DbContext 的生命周期管理（Scoped/Transient）错误也会间接导致底层连接不归还
• 用 PerfMon 监控 .NET Data Provider for SqlServer\NumberOfPooledConnections 和 NumberOfNonPooledConnections，前者长期 >80% 且缓慢爬升，基本就是泄漏信号