我在维护的 VB6（ADO/ODBC 到 SQL Server）应用程序中遇到了突然的性能下降问题，这似乎可以通过在一些 SELECT 查询之前添加 SET ARITHABORT ON 来解决。
问题是：在应用程序的每个选择查询中创建一个通用过程来设置 ARITHABORT ON 是否明智？这样做有什么危险？此设置是否会导致 SELECT 查询返回无效数据（尤其是如果它们包含聚合函数）而用户/开发人员没有注意到它？
更新：请记住，此应用程序在启用了合并复制的 SQL Server 2014 服务器上运行。
这表明您当前已关闭 ARITHABORT。这是一个非常糟糕的主意，微软甚至在BOL上添加了一个特定的警告：
“您应该始终在登录会话中将 ARITHABORT 设置为 ON。将 ARITHABORT 设置为 OFF 会对查询优化产生负面影响，从而导致性能问题。”
“警告 SQL Server Management Studio 的默认 ARITHABORT 设置为 ON。将 ARITHABORT 设置为 OFF 的客户端应用程序可以接收不同的查询计划，从而难以对性能不佳的查询进行故障排除。也就是说，相同的查询可以在 Management Studio 中快速执行，但在应用程序。使用 Management Studio 对查询进行故障排除时，始终与客户端 ARITHABORT 设置相匹配。”
所以，是的，我会将 ARITHABORT 设置为 ON，但从一开始就是这样。如果环境的其余部分被构建为期望 ARITHABORT OFF，我会非常犹豫改变这样一个基本的行为设置。
至于性能问题，您甚至不应该使用 ARITHABORT 设置来修复它。我会首先研究为什么会出现性能下降的数据。一定有什么改变了，如果你发现了什么，你可以用一种不太基本的方式来纠正它。