C#程序执行复杂SQL超时，需先在SSMS运行该查询才可正常执行

核心原因 #

数据库还原、快照恢复或重启后，SQL Server的执行计划缓存被清空。你的复杂查询（含多临时表、多表关联）首次执行时，SQL Server需要重新生成执行计划+完成初始数据扫描，这个过程耗时超过了C#客户端的命令执行超时时间（注意：你设置的Connect Timeout=0是控制「建立连接的超时」，和「查询执行超时」是两个完全不同的参数）。而SSMS执行一次后，执行计划被存入缓存，后续C#调用直接复用缓存计划，所以不再超时。

针对性解决方案 #

• 修正超时参数混淆
  你设置的Connect Timeout=0只影响数据库连接阶段，查询执行超时由SqlCommand.CommandTimeout控制（默认30秒）。在C#代码中给执行该查询的SqlCommand设置更大的超时值：

  using (var command = new SqlCommand(yourQuery, connection))
  {
      command.CommandTimeout = 120; // 设置为120秒，根据实际情况调整
      // 执行查询逻辑
  }
  

  生产环境不建议设为0（无超时），避免因异常查询占用资源。

• 提前缓存执行计划

  • 将查询封装为存储过程：存储过程的执行计划更易被SQL Server持久化缓存，首次执行后后续调用直接复用。如果需要强制更新计划，可在存储过程定义中添加WITH RECOMPILE，或调用时用EXEC YourProc WITH RECOMPILE。
  • 自动预热：在数据库重启/还原后，通过SQL Agent作业自动执行一次该查询，提前生成并缓存执行计划，避免业务程序首次执行超时。

• 优化查询与临时表

  • 给临时表添加索引：如果临时表数据量较大，关联时无索引会导致全表扫描，大幅拖慢首次执行速度。创建临时表后按需添加非聚集索引：

    CREATE NONCLUSTERED INDEX IX_Temp_KeyCols ON #TempTable(JoinCol1, FilterCol2);
    

  • 更新统计信息：数据库还原后统计信息可能过时，导致SQL Server生成低效执行计划。手动更新涉及表的统计信息：

    UPDATE STATISTICS dbo.Table1;
    UPDATE STATISTICS dbo.Table2;
    -- 对查询涉及的所有用户表执行更新
    

• 调整并行执行策略
  复杂查询可通过并行执行加速，可在查询末尾添加并行度选项（根据服务器CPU核心数调整，比如8核服务器设为8）：

  -- 在你的查询末尾添加
  OPTION (MAXDOP 8);
  

  也可检查数据库的MAXDOP全局设置，确保符合服务器硬件配置。

补充说明 #

多次运行C#程序偶尔正常，是因为前几次执行后SQL Server已生成并缓存了执行计划，后续调用直接复用；其他应用出现类似问题，也验证了是数据库层面的执行计划缓存问题，而非单个应用的代码问题。

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