从C#调用SQL Server存储过程超时，SSMS执行正常问题排查

这种情况我在项目里碰到过好多次，大概率是执行计划、参数传递或者C#端配置的差异导致的，咱们一个个排查：

1. 参数嗅探（Parameter Sniffing）不匹配 #

SSMS里你测试用的XML参数（比如主键数量）和C#实际传递的参数差异很大，导致SQL Server生成的执行计划不适用。比如你在SSMS用10条主键测试，生成的计划对小数据量高效，但C#传几百条时，这个计划就会变得异常缓慢，最终超时。

• 解决思路：
  • 在存储过程的查询语句末尾加 OPTION (RECOMPILE)，强制每次执行都生成适配当前参数的新计划（适合参数波动大的场景）；
  • 把外部传入的XML参数赋值给存储过程内部的局部变量，再用局部变量处理，绕开SQL Server的参数嗅探；
  • 使用 OPTION (OPTIMIZE FOR UNKNOWN)，让SQL Server基于统计信息的平均值生成通用执行计划。

2. C#端超时时间设置过短 #

SSMS默认的查询超时是无限制（0），但C#的SqlCommand默认超时只有30秒！你的存储过程跑45秒，刚好超过这个阈值，自然触发超时错误。

• 解决思路：
  • 创建SqlCommand时手动设置超时时间，比如：

    using (var command = new SqlCommand("YourStoredProcName", connection))
    {
        command.CommandType = CommandType.StoredProcedure;
        command.CommandTimeout = 120; // 设置为120秒，根据实际情况调整
        // 添加参数...
    }
    

3. XML参数传递方式不正确 #

C#传递XML参数时，如果没指定正确的参数类型，SQL Server需要额外做类型转换，或者XML格式/编码和SSMS测试时不一致，都会拖慢解析效率。

• 解决思路：
  • 明确指定参数类型为SqlDbType.Xml，避免默认的nvarchar转换：

    var xmlParam = new SqlParameter("@YourXmlParamName", SqlDbType.Xml);
    xmlParam.Value = new SqlXml(new XmlTextReader(new StringReader(yourXmlContent)));
    command.Parameters.Add(xmlParam);
    

  • 核对C#传递的XML和SSMS测试用的XML格式完全一致，比如有没有多余的命名空间、特殊字符处理差异。

4. 临时表统计信息缺失 #

存储过程里用了临时表，当数据量波动大时，SQL Server对临时表的统计信息可能不准确，导致执行计划选择低效的关联或查询方式。

• 解决思路：
  • 在临时表插入数据后，手动更新统计信息：UPDATE STATISTICS #YourTempTable;；
  • 如果是SQL Server 2014及以上版本，开启AUTO_UPDATE_STATISTICS_ASYNC，让统计信息异步更新，避免阻塞；
  • 不要盲目替换成表变量——表变量的统计信息更有限，大数据量下反而会更慢。

5. 连接上下文设置差异 #

SSMS和C#的数据库连接可能用了不同的SET选项（比如ARITHABORT、ANSI_NULLS），这些选项会影响执行计划的生成。SQL Server会根据连接的SET选项生成不同的计划，可能SSMS的配置让计划更高效，而C#默认配置导致计划变慢。

• 解决思路：
  • 在存储过程开头显式设置统一的SET选项，比如：

    SET ARITHABORT ON;
    SET ANSI_NULLS ON;
    SET ANSI_PADDING ON;
    SET ANSI_WARNINGS ON;
    SET CONCAT_NULL_YIELDS_NULL ON;
    SET NUMERIC_ROUNDABORT OFF;
    SET QUOTED_IDENTIFIER ON;
    

  • 或者在C#的连接字符串中添加对应的设置，确保和SSMS的连接上下文一致。

6. 锁与阻塞问题 #

C#调用时，可能刚好遇到其他进程锁定了相关资源，导致存储过程等待时间过长超时，而SSMS测试时没有这个冲突。

• 解决思路：
  • 用SQL Server Profiler或Extended Events跟踪阻塞情况，排查是否有锁等待；
  • 优化存储过程中的事务逻辑，尽量缩短事务时间，避免长时间持有锁；
  • 谨慎使用NOLOCK提示（仅在允许脏读的场景下），减少锁等待。

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