兄弟，我来帮你捋捋这个问题——你更换数据库服务器后，连接池超时错误从每日几十次飙升到数千次，已经排查了常规的连接释放、连接池大小、SQL Server连接数设置，但问题依旧，而且同Web服务器上的其他应用连接同一SQL Server完全正常。这说明问题大概率不是通用的连接池配置问题，而是你的应用与新DB服务器之间的特定交互，或者新服务器的针对性配置遗漏。下面给你几个具体的排查方向：

1. 先确认连接池被占满的真实原因 #

首先在SQL Server上运行以下查询，查看你的应用当前的活跃会话状态：

SELECT 
    s.session_id,
    s.status,
    s.program_name,
    s.login_name,
    t.text AS running_query,
    s.last_request_start_time
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE s.program_name = '你的应用程序名称' -- 替换成你的应用标识
ORDER BY s.last_request_start_time DESC;

• 如果大量会话处于running状态，说明你的应用查询在新服务器上执行变慢（比如索引缺失、硬件性能不足），导致连接被长时间占用，池内连接快速耗尽；
• 如果很多会话处于sleeping状态但last_request_end_time很久远，那可能存在隐性连接泄漏（哪怕用了using，也不排除ORM框架或边缘异常场景的问题）。

同时查看SQL Server的等待统计，排查阻塞连接的瓶颈：

SELECT 
    wait_type,
    wait_time_ms,
    wait_count
FROM sys.dm_os_wait_stats
WHERE wait_type IN ('LCK_M_*', 'PAGEIOLATCH_*', 'CONNECTIVITY_DB')
ORDER BY wait_time_ms DESC;

重点关注IO等待（PAGEIOLATCH_*）和锁等待（LCK_M_*），这些会拖慢查询执行，间接耗尽连接池。

2. 排查Windows身份验证的特殊问题 #

你用的是专用Windows用户做身份验证，新服务器上可能存在验证环节的延迟：比如AD域响应慢、用户登录权限设置异常。可以临时改用SQL Server身份验证测试，如果错误大幅减少，那问题就出在Windows身份验证环节，需要检查新服务器的DNS解析、域控制器响应速度，或者该用户的登录权限配置。

3. 检查新SQL Server的TCP/IP与线程配置 #

虽然你加了TransparentNetworkIPResolution=False，但还是要确认：

• 打开SQL Server配置管理器，禁用TCP动态端口，改用固定端口；
• 检查新服务器的防火墙、网络设备是否存在连接建立延迟（比如负载均衡器超时设置）；

另外查看SQL Server的最大工作线程数：

SELECT max_workers_count FROM sys.dm_os_sys_info;

如果应用会话数接近这个值，SQL Server会无法处理新连接请求。默认值是根据CPU核数自动设置的，若服务器多核但数值偏低，可以手动调大（服务器属性>处理器>最大工作线程数）。

4. 排查资源调控器或用户级连接限制 #

新服务器上有没有配置资源调控器，限制了你的专用Windows用户的连接数或资源？运行以下查询检查：

SELECT * FROM sys.resource_governor_resource_pools;
SELECT * FROM sys.resource_governor_workload_groups;

如果有针对该用户的分类规则，可能会限制其可用资源，导致连接池超时。同时检查该Windows用户的登录属性，确认没有设置用户级的连接数限制。

5. 验证应用端的隐性连接泄漏 #

虽然你说用了using或finally，但建议在应用端加日志追踪连接的打开/关闭：

using (var conn = new SqlConnection(connectionString))
{
    Logger.Info($"Connection opened: {conn.ClientConnectionId}");
    conn.Open();
    // 执行数据库操作
}
Logger.Info($"Connection closed: {conn.ClientConnectionId}");

这样能快速定位是否有连接在异常场景下未被正确释放。

内容的提问来源于stack exchange，提问作者ordiminnie