MVC应用遇Execution Timeout Expired问题，求排查方向

首先，sp_reset_connection是ADO.NET连接池的内置正常机制——当你的应用从连接池中复用一个已有的数据库连接时，SQL Server会自动调用这个存储过程，重置该连接的会话状态：包括清除未提交事务、重置上下文设置（如语言、隔离级别）、关闭游标等，确保每个复用的连接都是“干净”的，能被新请求安全使用。所以你在跟踪里看到这个语句，本身不是错误，而是连接池在正常工作的标志。

接下来结合你的情况和异常信息，分析超时问题的可能根源：

1. 为什么Profiler没抓到超时/长耗时记录？ #

你提到只看到RPC:Starting exec sp_executesql、SP:StmtStarting但没有结束事件，可能有几个原因：

• 跟踪事件不全：你可能没勾选RPC:Completed、SP:Completed、SQL:BatchCompleted这些关键事件，导致服务器端已完成执行，但你没看到结束记录；
• 阻塞未被捕捉：如果你的查询被其他会话阻塞，服务器端会一直等待资源，此时Profiler里只会有Starting事件，直到阻塞解除才会生成Completed记录；建议添加Blocked Process Report事件（需先开启blocked process threshold配置）来捕捉阻塞情况；
• 会话跟踪范围偏差：如果Profiler仅跟踪了特定数据库或用户，可能漏掉了目标会话的执行记录。

2. 结合异常栈的超时根源 #

从你的StackTrace可以看到，超时发生在SqlDataReader.get_MetaData()阶段——这说明客户端在尝试获取查询结果的元数据（如列名、数据类型）时，等待服务器响应超时了。结合InnerException的The wait operation timed out，这是客户端层面的超时，可能的原因包括：

• 查询本身执行慢但未被捕捉：比如查询涉及复杂JOIN、大表扫描或缺少索引，导致服务器执行时间超过了CommandTimeout（默认30秒）；
• 连接池压力：如果连接池耗尽（比如应用存在连接泄漏，未正确释放连接），请求在等待从池里获取可用连接时超时，此时sp_reset_connection的调用可能因等待连接池资源而卡住；
• 网络问题：服务器端已完成执行，但网络延迟或丢包导致客户端未及时收到响应，触发超时；这种情况下Profiler里会有Completed事件，但客户端仍会报超时；
• 元数据获取慢：如果查询涉及大量列、复杂视图，或者系统目录视图（如sys.tables）本身访问慢，也会导致元数据获取超时。

3. 排查步骤建议 #

针对你的场景，我建议按以下顺序排查：

• 检查CommandTimeout设置：确认应用代码中SqlCommand.CommandTimeout的值，如果是网格查询可能返回大量数据，可适当调大这个值（比如设为60或120秒），观察是否解决问题；
• 补全Profiler跟踪事件：添加RPC:Completed、SP:Completed、SQL:BatchCompleted、Blocked Process Report，重新跟踪确认是否有长耗时查询或阻塞；
• 检查连接池状态：在SQL Server上执行以下查询，查看连接池相关的等待和连接数：

  -- 查看当前总连接数
  SELECT COUNT(*) AS TotalConnections FROM sys.dm_exec_connections;
  -- 查看等待连接池资源的任务
  SELECT * FROM sys.dm_os_waiting_tasks WHERE wait_type LIKE '%POOL%';
  -- 查看连接池相关的等待统计
  SELECT wait_type, wait_time_ms, signal_wait_time_ms, waiting_tasks_count 
  FROM sys.dm_os_wait_stats 
  WHERE wait_type IN ('WAIT_FOR_CONNECTION_POOL', 'CONNECTION_POOL_LOCK')
  ORDER BY wait_time_ms DESC;
  

• 检查连接泄漏：确保应用代码中所有SqlConnection都用using语句包裹，保证连接被正确释放回池：

  using (var conn = new SqlConnection(connectionString))
  {
      conn.Open();
      // 执行查询逻辑
  }
  

• 分析服务器端等待统计：执行以下查询，定位是否存在IO、锁等瓶颈：

  SELECT wait_type, wait_time_ms, signal_wait_time_ms, waiting_tasks_count
  FROM sys.dm_os_wait_stats
  WHERE wait_time_ms > 0
  ORDER BY wait_time_ms DESC;
  

  比如PAGEIOLATCH_SH说明磁盘IO慢，LCK_M_X说明有锁阻塞，这些都会导致查询执行超时。

总结 #

sp_reset_connection本身不是问题，它是连接池正常工作的表现。你的超时问题大概率和查询执行慢、连接池压力、阻塞或网络问题有关，建议从上述排查步骤入手，逐步定位根源。

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