连接池耗尽的典型表现是抛出Timeout expired异常或日志中频繁出现Timeout while trying to acquire a connection；快速确认方式是检查是否未正确释放连接，如未用using语句或未调用Dispose()，导致连接泄漏。
连接池满了的典型表现和快速确认方式
应用抛出 Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. 异常，或日志中频繁出现 System.InvalidOperationException: Timeout while trying to acquire a connection，基本可以断定是连接池耗尽。这不是数据库本身扛不住，而是 SqlConnection 在客户端侧拿不到空闲连接 —— 池子里的连接全被“占着不还”或“回收太慢”。
最常踩的坑：没正确释放连接
SqlConnection 必须显式关闭，或用 using 语句确保 Dispose() 被调用。手动调 Close() 不够可靠（异常路径可能跳过），而只靠 GC 回收几乎必然导致连接泄漏。
using (var conn = new SqlConnection(connectionString))
{
conn.Open();
using (var cmd = new SqlCommand("SELECT TOP 1 * FROM Users", conn))
{
cmd.ExecuteScalar(); // 即使这里抛异常，conn 和 cmd 仍会被自动释放
}
}- 避免写
new SqlConnection(...); conn.Open(); ...后靠finally { conn.Close(); }—— 容易漏、难维护 - 不要在
static字段里缓存SqlConnection实例 —— 连接不是线程安全的，且生命周期与池机制冲突 - EF Core 用户注意：
DbContext默认不共享连接，但若手动传入SqlConnection并长期持有，同样会卡住池
连接池参数调优的关键配置项
连接字符串里的池化参数直接影响行为。默认 Max Pool Size=100，看似够用，但在高并发短请求场景下，100 个连接可能瞬间被占满，尤其当某些查询慢或事务未及时提交时。
-
Max Pool Size：设太高会加重 SQL Server 负担（每个连接消耗内存和线程资源），建议先观察实际峰值连接数（查sys.dm_exec_sessions），再上浮 20%～30% -
Min Pool Size：设为 0（默认）更合理；设非零值会导致空闲连接长期占用资源，反而降低弹性 -
Connection Timeout：默认 15 秒，可适当缩短（如 5～8 秒），让失败更快暴露，避免线程长时间阻塞等待 -
Pooling=true必须保持开启 —— 关闭它等于放弃池化，每请求新建连接，性能雪崩
异步 + 连接复用才是高并发正解
同步 Open() 会阻塞线程，线程池耗尽后新请求连进池子的机会都没有。必须全面切换到异步 API，并配合合理的并发控制。
using (var conn = new SqlConnection(connectionString))
{
await conn.OpenAsync(); // 非阻塞，线程可复用
using (var cmd = new SqlCommand("UPDATE Orders SET Status=@s WHERE Id=@id", conn))
{
cmd.Parameters.AddWithValue("@s", "shipped");
cmd.Parameters.AddWithValue("@id", orderId);
await cmd.ExecuteNonQueryAsync(); // 同样异步
}
}- 避免在
async void方法中开连接 —— 异常无法捕获，连接可能永不释放 - 不要用
Task.Run(() => { conn.Open(); })伪装异步 —— 只是把同步操作扔到线程池，没解决根本问题 - 若业务逻辑天然需要串行（如库存扣减），用
SemaphoreSlim控制并发度，比硬抗 1000 个连接更稳
真正压垮池子的，往往不是并发量本身，而是连接“开了不关”“关得太慢”“等得时间太长”。检查代码里每个 SqlConnection 实例的生命周期，比盲目调大 Max Pool Size 有效得多。
