连接池耗尽时最常见的错误是“Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool”，表明连接池已满且无空闲连接，发生在Open()或OpenAsync()调用时，与数据库性能无关。
连接池耗尽时最常见的错误信息是什么
看到 Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool，基本可以断定是连接池已满且无空闲连接可用。这不是数据库宕了，而是你的应用在“排队等号”——而且队列已满，默认池大小是 100，超时默认 15 秒，超时后直接抛异常。
注意这个错误一定发生在 new SqlConnection(connectionString).Open() 或 await connection.OpenAsync() 这一步，不是查询执行时报的。
- 它和网络超时、SQL 超时（如
CommandTimeout）无关，别往数据库性能或语句优化上瞎猜 - 如果日志里反复出现该错误，且集中在某几个接口或时间段，大概率是连接泄漏或短时高并发未控流
- 连接池本身不跨 AppDomain / 进程，不同连接字符串（哪怕只差一个空格或分号）视为完全独立的池
如何确认是不是连接泄漏（没 Close/Dispose）
最直接的办法：在开发或测试环境开启连接池计数器，或用代码主动检查当前池状态。但更实用的是加一层轻量级诊断——在 SqlConnection 构造和释放处埋点。
例如，在 using (var conn = new SqlConnection(cs)) { ... } 外围加日志，或改用工厂方法统一管控：
public static SqlConnection CreateOpenConnection(string cs)
{
var conn = new SqlConnection(cs);
conn.StateChange += (s, e) =>
Debug.WriteLine($"[{DateTime.Now:HH:mm:ss.fff}] Conn {conn.GetHashCode():X} → {e.CurrentState}");
conn.Open();
return conn;
}- 重点观察是否大量连接长期停留在
Open状态却不再关闭 - 检查所有
SqlConnection实例是否都包裹在using块中；async/await场景下必须用await using（C# 8+）或确保DisposeAsync()被调用 - 特别警惕在
catch块里忘了conn?.Close()，或在finally里写成conn.Close()却没判 null ——Close()和Dispose()都可安全重复调用，但手动管理易出错
连接字符串里哪些参数直接影响池行为
池行为由连接字符串显式控制，不是靠代码逻辑“自动调节”。关键参数只有三个，但误配极常见：
-
Pooling=true（默认值）：启用池。设为false就彻底禁用——仅用于调试，生产禁用，否则每次新建物理连接，开销巨大 -
Max Pool Size=100（默认值）：池中最多允许多少个活动连接。别盲目调大，得先确认是不是真需要——调到 500 可能只是掩盖泄漏 -
Min Pool Size=0（默认值）：池空闲时保留的最小连接数。设为非零值（如 5）可减少首次请求延迟，但会常驻占用资源，对低频服务意义不大
其他如 Connection Timeout 控制的是“等连接”的超时，不是命令执行超时；Load Balance Timeout 仅用于故障转移场景，和池耗尽无关。
为什么 await using + 异步方法仍可能耗尽连接池
异步不等于自动释放。如果你写了 await conn.OpenAsync() 却没用 await using，或者在 Task.Run(() => { conn.Open(); }) 这类同步上下文中调用异步方法，连接可能被卡在未关闭状态。
-
await using var conn = new SqlConnection(cs)是目前最安全的写法，保证DisposeAsync()在作用域结束时触发 - 避免混合模式：不要在
async方法里调用conn.Open()（同步阻塞），也不要在线程池线程里用conn.OpenAsync()后忘记 await - EF Core 用户注意：
DbContext默认不共享连接，每次SaveChangesAsync()都会从池取新连接——若批量操作未用事务包裹，可能短时间内申请数十次连接
真正难排查的是那些“看起来用了 using，但被 try/catch 吞掉异常导致 dispose 跳过”的情况，或者依赖 DI 容器生命周期（如 Scoped）却在非请求上下文（Timer、BackgroundService）中误复用 DbContext。
