SqlCommand.ExecuteReader调用存储过程耗时久但DMV显示耗时短排查

以下是结合你的排查结果，梳理出的核心排查方向：

• 网络链路延迟
  遥测统计的是应用发起请求到响应完成的全链路时间，而sys.dm_exec_procedure_stats仅统计数据库端的执行耗时。如果应用服务器与Azure SQL之间的网络出现波动、跨区域路由跳转、带宽饱和等情况，会导致总耗时大幅增加，但数据库端执行速度不受影响。可以检查应用服务器到Azure SQL实例的网络往返时间（RTT），或通过Azure Monitor查看数据库的连接延迟指标。

• 连接池等待
  应用通过SqlCommand调用时，若连接池中无空闲连接可用，会等待新建连接或释放连接，这部分等待时间会被计入遥测的总耗时，但数据库端不会产生对应的执行记录。可以检查应用的连接池配置（如Max Pool Size），同时查看应用日志中是否存在连接超时、等待相关的报错或警告。

• 结果集的应用端处理耗时
  遥测的Duration可能包含了结果集读取与业务处理的时间：如果存储过程返回大量数据，应用通过SqlDataReader逐行读取、序列化或进行业务逻辑处理的耗时，不会被计入数据库端的执行统计。对比SSMS调用时返回的数据量，以及应用实际接收并处理的数据量是否一致，检查应用侧对结果集的处理逻辑。

• 事务上下文差异
  应用调用存储过程时可能处于未提交的事务中，且使用了更高的隔离级别（如Serializable），这可能导致存储过程执行时出现锁等待或阻塞；而SSMS调用通常在独立会话、默认隔离级别下执行，不会触发这类等待。检查应用代码中调用存储过程时的事务设置，对比SSMS执行时的事务上下文。

• 参数类型不匹配
  即使排除了参数嗅探，仍可能存在参数隐式转换问题：比如应用传递的参数类型与存储过程定义的类型不一致（如应用传字符串、存储过程参数为数值型），数据库会进行隐式转换，在特定数据量下可能导致执行计划效率下降，但这类异常执行可能因次数少未更新sys.dm_exec_procedure_stats的统计数据。检查应用代码中SqlParameter的类型定义，确保与存储过程参数类型完全匹配。

• Azure SQL临时资源瓶颈
  sys.dm_exec_procedure_stats的max_elapsed_time是统计周期内的最大值，但若异常耗时发生在数据库CPU、IO、内存临时饱和的时段（比如其他高负载查询抢占资源），该存储过程的执行会被延迟，事后正常执行的请求可能覆盖统计数据。查看Azure SQL对应异常时段的性能指标（CPU使用率、IO吞吐量、等待统计），确认是否有资源峰值。

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