EF Core 2.2调用SQL Server存储过程偶发超时异常问题咨询

问题1答案 #

你代码中显式给SqlCommand.CommandTimeout赋值的配置不会被忽略。
官方文档提及的异步方法忽略超时的场景仅存在于早期.NET Core预览版的特殊边缘情况，你当前使用的EF Core 2.2搭配的System.Data.SqlClient稳定版中，自行创建SqlCommand并显式指定超时的写法是完全生效的，不受EF Core层面配置的额外影响。

问题2答案 #

CommandTimeout的计时包含Reader读取数据的全部耗时。
该超时的统计周期从调用ExecuteReaderAsync()方法开始，到Reader读取完最后一行数据、或者命令被主动取消为止，不是仅统计存储过程在SQL Server内部的执行时间。网络传输慢、返回结果集过大、Reader读取过程中逻辑耗时高都可能触发超时。

问题3答案 #

可重点排查以下SQL Server侧配置及状态：

• 实例级worker线程配置：查询sys.dm_os_wait_stats是否存在THREADPOOL类型等待，确认是否因同实例其他数据库的高负载耗尽了可用工作线程，导致你的查询请求排队超时。
• TempDB配置：确认TempDB的数据文件个数是否和CPU核心数匹配（一般推荐1-8核每核一个文件，8核以上固定8个文件），autogrowth是否按固定大小增长而非百分比，避免TempDB争用导致的查询卡顿。
• 参数嗅探问题：查询sys.dm_exec_query_stats中对应存储过程的执行时间分布，确认是否存在执行计划缓存不合理，部分参数执行时计划失效导致耗时飙升的情况。
• 锁与阻塞：虽然你用了READUNCOMMITTED隔离级别，仍需排查后台插入任务是否触发锁升级为表锁，导致读请求被阻塞，可通过sys.dm_tran_locks和sys.dm_os_wait_stats的LCK_M_*类型等待确认。
• 数据库级配置：确认你的业务库是否开启了AUTO_CLOSE、AUTO_SHRINK属性，这两个属性会导致偶发的查询性能暴跌，建议关闭。
• 实例内存配置：检查SQL Server最大内存限制是否合理，是否存在内存不足导致频繁磁盘IO的情况，同时确认是否同实例其他数据库占用了大量内存，挤压了你的业务库的数据缓存。
• 网络层面：排查应用服务器到数据库服务器的链路是否存在偶发丢包、延迟飙升的情况，避免网络问题触发超时。

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