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% 且缓慢爬升，基本就是泄漏信号
