Windows服务应用调用存储过程出现SQL执行超时错误如何解决？

你修改的Connection Timeout配置仅作用于数据库连接建立阶段，和存储过程执行阶段的超时判断完全无关：

• Connection Timeout：控制客户端与SQL Server完成连接握手的最长等待时间，默认15秒，和SQL执行时长没有任何关系
• 你碰到的30秒超时是SqlCommand.CommandTimeout的默认值，这个配置才是控制单条SQL/存储过程执行的最长允许时长，单位为秒，默认值恰好为30秒，和你观察到的“改了连接字符串还是30秒抛错”的现象完全匹配。

• 首先确认配置修改的目标位置正确：实际执行数据库调用的是你被引用的Web应用，需要修改的是Web应用内的数据库访问代码/相关配置，而非仅修改Windows服务侧的配置文件，所有配置修改后需要重启对应服务/站点进程才会生效。
• 给执行存储过程的命令对象设置合理的执行超时：
  • 如果你是原生ADO.NET调用存储过程，在执行前显式给SqlCommand对象赋值CommandTimeout属性即可，参考代码：

  using (SqlConnection conn = new SqlConnection(你的数据库连接字符串))
  {
      SqlCommand cmd = new SqlCommand("目标存储过程名称", conn);
      cmd.CommandType = CommandType.StoredProcedure;
      // 根据存储过程实际执行时长设置，单位为秒，设置为0表示无超时（生产环境不推荐长期使用0值）
      cmd.CommandTimeout = 120;
      // 补充存储过程参数、执行数据库操作
      conn.Open();
      cmd.ExecuteNonQuery();
  }
  

  • 如果你使用EF/EF Core等ORM框架调用存储过程，需要单独给ORM上下文配置命令超时：
    • EF6：在DbContext构造函数中添加this.Database.CommandTimeout = 120;
    • EF Core：在DbContext初始化配置时添加optionsBuilder.UseSqlServer(连接字符串, o => o.CommandTimeout(120));

设置更长的超时只是临时兼容方案，45秒的存储过程执行时长本身存在优化空间，建议同步做以下排查：

• 先在SSMS中单独执行该存储过程，确认无参数嗅探、锁等待等异常情况，稳定复现45秒左右的执行时长后，针对性优化存储过程逻辑：检查是否存在大表全表扫描、缺失必要索引、长事务持锁不释放、不必要的循环处理等性能问题
• 排查Web应用内是否存在其他数据库访问拦截器、公共封装类硬编码了30秒的命令超时，覆盖了你修改的配置
• 确认数据库服务器CPU、内存、磁盘IO负载正常，不存在资源瓶颈导致的执行变慢

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