ARITHABORT OFF 对性能产生不利影响

Question

我完全知道来自应用程序的 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

Answer 1

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

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

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

这说明：

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

Answer 2

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