.Net SqlCommand.ExecuteNonQuery 中的查询超时，适用于 SQL Server Management Studio

Posted 2023-02-25

【中文标题】.Net SqlCommand.ExecuteNonQuery 中的查询超时，适用于 SQL Server Management Studio

【英文标题】：Query times out in .Net SqlCommand.ExecuteNonQuery, works in SQL Server Management Studio

【发布时间】：2010-11-02 06:43:37

【问题描述】：

更新：问题已解决，并一直在解决。 如果您想查看该网站的运行情况，请访问 Tweet08

我有几个查询在 SSMS 中的行为与在我的 .Net 应用程序中运行时的行为不同。 SSMS 在一秒钟内执行良好。 .Net 调用在 120 秒后超时（连接默认超时）。

我进行了 SQL 跟踪（并收集了所有内容），我发现连接选项是相同的（并且与 SQL Server 的默认设置相匹配）。然而，SHOWPLAN All 在行估计中显示出巨大的差异，因此工作版本会执行激进的 Table Spool，而失败的调用则不会。

在SSMS中，临时变量的数据类型基于.Net中生成的SQL参数，所以它们是相同的。

在 VS2008 调试会话中的 Cassini 下执行失败。成功是在 SSMS 2008 下。两者都在同一台机器上的同一网络上针对同一目标服务器运行。

SSMS 中的查询：

DECLARE @ContentTableID0 TINYINT
DECLARE @EntryTag1 INT
DECLARE @ContentTableID2 TINYINT
DECLARE @FieldCheckId3 INT
DECLARE @FieldCheckValue3 VARCHAR(128)
DECLARE @FieldCheckId5 INT
DECLARE @FieldCheckValue5 VARCHAR(128)
DECLARE @FieldCheckId7 INT 
DECLARE @FieldCheckValue7 VARCHAR(128)
SET @ContentTableID0= 3
SET @EntryTag1= 8
SET @ContentTableID2= 2
SET @FieldCheckId3= 14
SET @FieldCheckValue3= 'igor'
SET @FieldCheckId5= 33
SET @FieldCheckValue5= 'a'
SET @FieldCheckId7= 34
SET @FieldCheckValue7= 'a'

SELECT COUNT_BIG(*)
FROM dbo.ContentEntry AS mainCE
WHERE GetUTCDate() BETWEEN mainCE.CreatedOn AND mainCE.ExpiredOn
AND (mainCE.ContentTableID=@ContentTableID0)
AND ( EXISTS (SELECT *
              FROM dbo.ContentEntryLabel
              WHERE ContentEntryID = mainCE.ID
              AND GetUTCDate() BETWEEN CreatedOn AND ExpiredOn
              AND LabelFacetID = @EntryTag1))
      AND (mainCE.OwnerGUID IN (SELECT TOP 1 Name
                                FROM dbo.ContentEntry AS innerCE1
                                WHERE GetUTCDate() BETWEEN innerCE1.CreatedOn AND innerCE1.ExpiredOn
                                AND (innerCE1.ContentTableID=@ContentTableID2
                                     AND EXISTS (SELECT *
                                                 FROM dbo.ContentEntryField
                                                 WHERE ContentEntryID = innerCE1.ID
                                                 AND (ContentTableFieldID = @FieldCheckId3
                                                      AND DictionaryValueID IN (SELECT dv.ID
                                                                                FROM dbo.DictionaryValue AS dv
                                                                                WHERE dv.Word LIKE '%' + @FieldCheckValue3 + '%'))
                                                )
                                    )
                               )
           OR EXISTS (SELECT *
                      FROM dbo.ContentEntryField
                      WHERE ContentEntryID = mainCE.ID
                      AND (   (ContentTableFieldID = @FieldCheckId5
                               AND DictionaryValueID IN (SELECT dv.ID
                                                         FROM dbo.DictionaryValue AS dv
                                                         WHERE dv.Word LIKE '%' + @FieldCheckValue5 + '%')
                              )
                           OR (ContentTableFieldID = @FieldCheckId7
                               AND DictionaryValueID IN (SELECT dv.ID
                                                         FROM dbo.DictionaryValue AS dv
                                                         WHERE dv.Word LIKE '%' + @FieldCheckValue7 + '%')
                               )
                          )
                     )
          )

Trace 的 .Net 调用版本（添加了一些格式）：

exec sp_executesql N'SELECT COUNT_BIG(*) ...'
,N'@ContentTableID0 tinyint
,@EntryTag1 int
,@ContentTableID2 tinyint
,@FieldCheckId3 int
,@FieldCheckValue3 varchar(128)
,@FieldCheckId5 int
,@FieldCheckValue5 varchar(128)
,@FieldCheckId7 int
,@FieldCheckValue7 varchar(128)'
,@ContentTableID0=3
,@EntryTag1=8
,@ContentTableID2=2
,@FieldCheckId3=14
,@FieldCheckValue3='igor'
,@FieldCheckId5=33
,@FieldCheckValue5='a'
,@FieldCheckId7=34
,@FieldCheckValue7='a'

【问题讨论】：

SQL Server Standard 2005，不是发生这种情况的唯一查询，但非常具有代表性和可重复性。

发布调用这个的客户端代码。

你确定它们是一样的吗？如果您调用 .AddWithValue() .Net 将创建一个 NVarChar 参数而不是 VarChar 并且将无法使用任何 VarChar 索引。

在 SSMS 中，当它工作时，该语句会导致 86214 次逻辑读取。在 .Net 中，超时时会导致 746033 次逻辑读取（由于缺少 Table Spool）。

对不起，如果我听起来像个白痴。两个示例都指向同一个服务器/数据库吗？

【参考方案1】：

这不是你的索引。

这是参数嗅探，因为它通常发生在参数化存储过程中。它并不广为人知，即使在那些知道参数嗅探的人中，但也可能在您通过 sp_executesql 使用参数时发生。

您会注意到，您在 SSMS 中测试的版本与探查器显示的版本不相同，因为探查器版本显示您的 .Net 应用程序正在通过 sp_executesql 执行它。如果您提取并执行实际正在为您的应用程序运行的完整 sql 文本，那么我相信您会在相同的查询计划中看到相同的性能问题。

仅供参考：不同的查询计划是参数嗅探的关键指标。

修复：假设它在 SQL Server 2005 或 2008 上执行，修复此问题的最简单方法是将子句“OPTION (RECOMPILE)”添加为 SELECT 语句的最后一行。请注意，您可能需要执行两次才能使其工作，而且它并不总是在 SQL Server 2005 上工作。如果发生这种情况，那么您可以采取其他步骤，但它们会涉及更多。

您可以尝试的一件事是检查并查看是否已为您的数据库启用“强制参数化”（它应该位于“选项”页面下的 SSMS 数据库属性中）。要关闭强制参数化，请执行以下命令：

    ALTER DATABASE [yourDB] SET  PARAMETERIZATION SIMPLE 

【讨论】：

您对 sp_executesql 的看法是正确的，如果这是原因，我会感到惊讶，因为这只是针对可能匹配计划缓存（重新启动）的服务器的语句。我不能对我的代码生成器所做的每条语句强制重新编译，这会影响服务器。我可以以某种方式禁用参数化吗？

参数嗅探与获取其他语句的计划没有任何关系，这与具有不同参数的相同查询应该获得不同计划以获得最佳性能这一事实有关。但是，一旦参数化，查询将卡在或冻结在一个对大多数（甚至所有）参数都不利的计划上。

感谢您的信息，我们没有打开强制参数化（我确认服务器和此数据库已关闭）。至于不同的参数，不......相同的确切查询是发送到此服务器的唯一值。事实上，鉴于 bug 的性质，唯一可能改变的值是 (evil, ICK!!) LIKE '%' + @parameter + '%' 子句中间的字符串。据我所知，这在服务器中很奇怪。似乎在重新启动后表现良好。

如果相同的查询，相同的值会根据参数化与否产生不同的执行计划，这就是参数嗅探，因为这就是参数嗅探的定义。

我还没有弄清楚为什么它使用 sp_executesql 并对其进行如此多的参数化，因为我认为简单的参数化不会走那么远。

【参考方案2】：

我今天遇到了这种情况，解决我的问题的方法是在对表格进行选择时使用WITH (NOLOCK)：

例如：如果您的存储过程具有如下所示的 T-SQL：

SELECT * FROM [dbo].[Employee]

改成

SELECT * FROM [dbo].[Employee] WITH (NOLOCK)

希望这会有所帮助。

【讨论】：

这当然可以消除锁争用......但可能会产生陈旧（坏）的数据。

【参考方案3】：

我以前做过非工作时间的工作，但我得到的结果和你描述的一样。 sp_recompile 可以重新编译 sproc...，或者，如果这不起作用，则可以在 table 上运行 sp_recompile，并且将重新编译作用于该 table 的所有 sproc——每次都对我有用。

【讨论】：

游戏中没有存储过程。更新了统计数据，重建了所有索引。

【参考方案4】：

我之前也遇到过这个问题。听起来你的索引不正常。要在 SSMS 中获得相同的行为，请将其添加到脚本之前

SET ARITHABORT OFF

它也会超时吗？如果是这样，那就是您的索引和统计数据

【讨论】：

试过了，没有任何改变。连接、数据库和服务器默认设置为 ARITHABORT ON。跟踪显示两个连接的相同连接选项： -- 网络协议：TCP/IP 设置quoted_identifier on set arithabort on set numeric_roundabort off set ansi_warnings on set ansi_nulls on set concat_null_yields_null on set cursor_close_on_commit off set implicit_transactions off set language us_english set dateformat mdy set datefirst 7 设置事务隔离级别读取提交

没有改变任何东西，我的意思是我将它添加到 SSMS 中，它仍然在亚秒时间内完成。

遇到同样的问题，SET ARITHABORT OFF 也会导致 SSMS 超时。那么如果是索引/统计，我们如何解决或重建它们？

所以我重建了索引 (sql-server-performance.com/tips/rebuilding_indexes_p1.aspx)，问题就消失了。看起来我们需要一个维护计划 (ssw.com.au/ssw/Standards/Rules/…) 或类似的东西来防止这种情况。知道为什么它首先会发生吗？

【参考方案5】：

这很可能与索引有关。 .Net 应用程序与 SSMS 有类似的问题（特别是在使用

【讨论】：

所有表都有你可能想要的所有索引（正确的类型）。该计划只显示快乐路径计划元素。

【参考方案6】：

已检查，此服务器（开发服务器）未运行 SQL Server 2005 SP3。试图安装它（需要重新启动），但它没有安装。奇怪的是，现在代码和 SSMS 都在亚秒时间内返回。

哇，这是一只海森堡。

【讨论】：

这只是因为您刷新了查询计划缓存。除非你修复它，否则它会回来。

我同意它应该是因此。然而它再也没有回来。我怀疑在重新启动时安装的 Windows 更新之一有一些影响。 Hyper-V 主机中的那个或某些东西很高兴。

【参考方案7】：

我以前见过这种行为，这对于使用 sp_executesql 的 o/r 映射器来说可能是个大问题。如果您检查执行计划，您可能会发现 sp_executesql 查询没有很好地利用索引。我花了相当多的时间试图找到解决此行为的方法或解释，但没有得到任何结果。

【参考方案8】：

您的 .Net 程序很可能将变量作为 NVARCHAR 而不是 VARCHAR 传递。您的索引位于我假设的 VARCHAR 列上（从您的脚本判断），并且像 ascii_column = @unicodeVariable 这样的条件实际上是不支持 SARG 的。在这种情况下，计划必须生成一次扫描，而在 SSMS 中会生成一次搜索，因为变量是正确的类型。

确保将所有字符串作为 VARCHAR 参数传递，或修改查询以显式转换变量，如下所示：

SELECT dv.ID
FROM dbo.DictionaryValue AS dv
WHERE dv.Word LIKE '%' + CAST(@FieldCheckValue5 AS VARCHAR(128)) + '%'

【讨论】：

不，抱歉。再次阅读问题...我显示了 .Net 跟踪的调用，它正在传递完全正确的数据类型。我们的访问层做到了这一点。