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文章指出：

接下来，当涉及到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

- Chris Walsh

---

抱歉，那是一个打错的字。我会更正的，在两种情况下都保持 SET ANSI_WARNINGS ON。 - Chris Walsh

好的。我刚刚发现了另一个影响我的查询的隐藏变量。虽然我正在运行SQL Server 2014，但数据库处于“SQL Server 2008（100）”兼容模式下（与我们的生产数据库相同）。当我将其切换到“SQL Server 2014（120）”时，两个查询现在以相同的时间顺序运行。因此，文章中的语句是否也可以有条件地适用于SQL Server 2005之后的兼容级别？ - Chris Walsh

@MartinSmith，我知道这里有不同的缓存计划，并且“稍微更改文本”可能会导致查询运行速度快（由于上一个计划被抛弃），但是...我已经尝试过了，并且单独运行第93个调用（跳过前92个），它仍然无限期地运行！将兼容性级别设置为120后，两者现在都可以工作，并且当我将兼容性级别设置为100时，两者仍然可以工作。将兼容性级别120更改是否对数据库结构产生了不可逆转的影响？ - Chris Walsh

我将再次恢复数据库并尝试这些选项。干杯。 - Chris Walsh

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

Answer 1

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

我在MSDN参考ARITHABORT中找到了这段话：

当数据库兼容性级别设置为90或更高时，将ANSI_WARNINGS设置为ON会隐式地将ARITHABORT设置为ON。如果数据库兼容性级别设置为80或更早版本，则必须显式地将ARITHABORT选项设置为ON。

这解释了：

1. 为什么我改变ARITHABORT时得到了一个不同的结果，尽管ANSI_WARNINGS已经设置为ON。（数据库级别为80）
2. 为什么改变数据库级别似乎修复了问题（因为我将其更改为120）

- Chris Walsh

Answer 2

你发布的文章是误导性的。如果 ansi_warnings 是开启的，而 arithabort 是关闭的，你作为人知道这对查询没有影响。但是 SQL Server 引擎不知道这是否有影响，并将自动强制获取新的执行计划并且不使用缓存的计划。这意味着，如果你遇到参数嗅探问题并且有一个错误的计划，当 arithabort 开启时，你将永远不会得到那个错误的计划并使用它。这就是使该设置成为发现参数嗅探的好测试的原因。使用 optimize for unknown 提示进行参数嗅探，而不是更改数据库兼容性级别，这可能会影响其他事情。

- N. Rhoades

---

谢谢您的反馈。我需要一些时间来消化您的观点，但我认为您提出了一些非常好的观点，我需要理解清楚。谢谢。 - Chris Walsh