ARITHABORT OFF 对性能产生不利影响

Posted 2023-04-14

【中文标题】ARITHABORT OFF 对性能产生不利影响

【英文标题】：ARITHABORT OFF adversely affecting performance

【发布时间】：2015-07-09 09:06:53

【问题描述】：

我完全知道来自应用程序的 SQL 查询通常使用 SET ARITHBAORT OFF，而 SSMS（默认情况下）使用 SET ARITHBAORT ON。我也相信SET ARITHBAORT OFF 只是为了与旧版兼容而存在，真正的查询应该使用SET ARITHBAORT ON 运行。

我有一个作为 C# 控制台应用批处理文件的一部分运行的查询。使用SET ARITHBAORT OFF 和SET ANSI_WARNINGS ON 准备上下文（默认情况下）。前 92 个调用执行良好，第 93 个调用总是锁定（每个调用使用不同的参数）。如果我在使用第 93 次调用中的参数调用存储过程之前使用 SET ARITHBAORT OFF，我已经能够在 SSMS 中重现这一点。

那么我的问题（抱歉到目前为止的背景信息）.... Erland Sommarskog article 声明：

接下来，说到ARITHABORT，大家应该知道，在SQL 2005及以后的版本中，只要ANSI_WARNINGS为ON，这个设置的影响为零。因此，没有理由为了这件事而打开它。

但是，我使用的是 SQL Server 2014，我发现：

SET ARITHBAORT ON
SET ANSI_WARNINGS ON
EXEC mySP   -- Runs efficiently

运行良好，但

SET ARITHBAORT OFF
SET ANSI_WARNINGS ON
EXEC mySP   -- Runs indefinitely

无限期运行。因此，如果SET ANSI_WARNINGS ON 使ARITHBAORT 选项无关紧要，为什么我的查询会锁定？ 谢谢。

http://www.sommarskog.se/query-plan-mysteries.html

【问题讨论】：

我不确定我是否遵循您的推理，因为在您的上一个示例中，您似乎也设置ANSI_WARNINGSOFF，那么它有什么影响什么时候打开是无关紧要的。

抱歉，打错了。我会更正它，我在这两种情况下都保留SET ANSI_WARNINGS ON。

好的。我刚刚发现了另一个影响我的查询的隐藏变量。虽然我运行的是 SQL Server 2014，但数据库处于“SQL Server 2008 (100)”兼容模式（根据我们的实时数据库）。当我将其切换到“SQL Server 2014 (120)”时，两个查询现在都以相同的时间顺序运行。那么文章中的语句是否也可以以 SQL Server 2005 之后的兼容性级别为条件？

@ChrisWalsh - 不同的缓存计划。参数嗅探。如果您在第 93 次调用时稍微更改查询的文本并使用 ARITHBAORT OFF 运行它，您可能会发现它运行速度与生成一个对这些参数有益的新计划一样快。

关于更改兼容级别的影响，SQL 2014 包含一个新的查询优化器 - 但仅在兼容级别为 120 (msdn.microsoft.com/en-us/library/bb510680.aspx) 时使用。在 110 或以下，使用旧的 optimister。这或许可以解释您所看到的。

【参考方案1】：

好的。所以我从 Sommarskog 文章中引用的语句是在数据库级别为 80 或更高的条件下。

我在MSDN reference for ARITHABORT找到了这一段：

将 ANSI_WARNINGS 设置为 ON 会在 数据库兼容级别设置为 90 或更高。 如果数据库 兼容级别设置为 80 或更早，ARITHABORT 选项 必须明确设置为 ON。

这说明：

为什么即使 ANSI_WARNINGS 设置为 ON，我在更改 ARITHABORT 时还是会有所不同。 （数据库级别为 80） 为什么更改数据库级别似乎可以解决问题（因为我将其更改为 120）

【参考方案2】：

您发布的文章具有误导性。如果 ansi_warnings 为 ON 并且 arithabort 已关闭，那么您知道这对您的查询没有影响。 sql server 引擎不知道这是否会有所不同，并且会自动强制获取新的执行计划而不使用您的缓存计划。这意味着如果您遇到参数嗅探问题并且有一个糟糕的计划，您将永远不会得到那个糟糕的计划并在 arithabort 开启的情况下使用它。这就是使该设置成为查找参数嗅探的绝佳测试的原因。使用优化未知提示进行参数嗅探，而不是更改可能影响其他事情的数据库兼容性级别。

【讨论】：

感谢您的反馈。我需要一点时间来消化你的观点，但我认为你有一些非常好的观点，我需要弄清楚。谢谢。