ASP.NET MVC与SQL Server 2014执行超时错误求助

首先得明确：你遇到的Web应用30秒超时和数据库连接超时是两个完全独立的问题，咱们拆解开来一步步排查解决：

1. 先确保Web端超时配置真正生效 #

你在web.config的system.web节点加了executionTimeout="36000"，但这个配置有几个生效前提：

• 仅对同步请求有效，如果你的Web应用用了异步Action/方法，这个全局设置不会起作用，得单独配置异步超时（比如ASP.NET MVC里的[AsyncTimeout]属性）
• 检查IIS应用池的配置：应用池的「进程模型」里有没有设置更短的「闲置超时」或「请求限制」，这些会覆盖web.config的配置
• 如果是ASP.NET Core项目，httpRuntime配置不适用，得用Kestrel的超时设置或者中间件来控制请求超时

2. 别混淆数据库连接超时和查询执行超时 #

你设置的Connect Timeout = 300000是建立数据库连接的超时时间，和存储过程的执行时长完全没关系！真正控制查询执行超时的是SqlCommand的CommandTimeout属性：

• 如果你用ADO.NET直接调用存储过程，要显式设置：cmd.CommandTimeout = 60;（设为大于42秒的值即可）
• 如果用EF框架：
  • EF6里可以在上下文里设置：db.Database.CommandTimeout = 60;
  • EF Core里要在配置连接时指定：optionsBuilder.UseSqlServer(connectionString, o => o.CommandTimeout(60));

3. 优化存储过程才是根本解决办法 #

不管怎么调超时，42秒的存储过程肯定存在性能瓶颈，这才是问题根源：

• 查看执行计划：在SSMS里按Ctrl+M开启「包括实际执行计划」，然后执行存储过程，重点找表扫描、缺失索引、键查找这些耗时点
• 更新精准统计信息：exec sp_updatestats是轻量更新，试试对存储过程涉及的大表执行全量统计更新：UPDATE STATISTICS [你的表名] WITH FULLSCAN;
• 排查参数嗅探问题：如果存储过程的执行计划因为参数不同变得低效，可以在存储过程末尾加OPTION (RECOMPILE)，或者用局部变量接收输入参数后再使用
• 简化存储过程逻辑：有没有不必要的循环、大表无索引关联、临时表使用不当这些情况？逐步拆解存储过程的步骤，定位哪一段最耗时

4. 额外排查点 #

• 检查网络：用ping和tracert测试Web服务器到数据库服务器的网络延迟，有没有丢包情况
• 查看数据库负载：用SSMS的「活动监视器」或者执行sp_who2，看看有没有其他高资源占用的查询在和你的存储过程抢资源

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