SQL Server：为什么不对 ANSI_NULLS 使用默认数据库设置？

Question

我遇到过一个客户遇到此错误的情况 - 偶尔会出现：

消息 8624，级别 16，状态 21，第 1 行
内部查询处理器错误：查询处理器无法生成查询计划。有关更多信息，请联系客户支持服务。

他们正在使用我们的软件，并在 SQL Server 2008 R2 (RTM) 和兼容性级别 100 (SQL Server 2008) 上运行它。然而，该数据库最初是在 2000 年或 2005 年的机器上创建的（无法再复制），然后最近移至 2008 R2。

有问题的存储过程有一个看起来很丑的INSERT语句，它从给定表的十个（是的！）“副本”中获取数据，所有这些都相互连接RIGHT OUTER JOIN（同一个表 - 十个与之相对的 JOIN）。

我发现似乎最合适的一种解决方案与各种设置有关 - 建议使用：

set ANSI_NULLS ON
set ANSI_PADDING ON
set ANSI_WARNINGS ON
set CONCAT_NULL_YIELDS_NULL ON
set QUOTED_IDENTIFIER ON
set ARITHABORT ON

set NUMERIC_ROUNDABORT OFF 

好的 - 当然 - 我可以在我创建（或更改）的每个存储过程之前设置这些。

我向数据库专家提出的问题是：将这些设置为我的数据库的默认设置有什么风险吗？

例如

ALTER DATABASE MyDB SET ANSI_NULLS ON

并完成它？想法？见解？推荐？

Answer 1

这根本不是风险。事实上，ANSI_NULLS 关闭能力的寿命是有限的。很快，这甚至不会成为一种选择，它将始终处于ON 状态。我唯一一次看到设置ANSI_NULLS OFF 的任何形式的推理，是因为有些开发人员无法理解 的真正含义NULL，因此想要使用典型的条件逻辑。再次，可怕的推理，没有道理。我期待着永久开启设置ANSI_NULLS。