为什么在SET ARITHABORT ON上可以大大加快查询速度？
Answers:
有点过时了，但是对于任何在这里遇到类似问题的人来说...
我有同样的问题。对我来说，原来是参数嗅探，起初我对它并不了解。我添加了一个'set arithabort on'来解决问题，但后来又回来了。然后我读到：
http://www.sommarskog.se/query-plan-mysteries.html
它清除了所有内容。因为我使用的是Linq to SQL，并且解决该问题的选项有限，所以我最终使用了一个查询计划指南（请参阅链接结尾）来强制执行我想要的查询计划。
我认为这几乎可以肯定是参数嗅探。
人们通常说这SET OPTIONS可能会以这种方式影响性能，但是除了使用索引视图/持久化计算列的情况外，我还没有看到此声明的权威来源。
在这种情况下（对于SQL2005 +，除非您的数据库处于SQL2000兼容模式下）。如果同时拥有两者ARITHABORT，ANSI_WARNINGS OFF则将发现索引未被使用，因此可能是扫描而不是所需的查找（以及一些开销，因为无法使用持久的计算结果）。ADO.NET似乎默认使用ANSI_WARNINGS ON我刚刚进行的快速测试。
该要求在Ben的回答说：“服务器进行数值计算的方式”可以添加分钟，否则将采取不到一秒钟的结果似乎并不可靠的给我。我认为趋向于发生的是，在调查性能性能问题后，探查器用于识别有问题的查询。将其粘贴到Management Studio中并运行并立即返回结果。连接之间唯一明显的区别是ARITH_ABORT选项。
在Management Studio窗口中进行的快速测试表明，当SET ARITHABORT OFF打开电源并运行查询时，性能问题就会再次发生，因此显然已关闭案例。实际上，这似乎是Gregg Stark链接中使用的故障排除方法。
但是，这忽略了以下事实：使用该选项集，您最终可能会从缓存中获得完全相同的错误计划。
即使您以不同于应用程序连接使用的用户身份登录，也会重复使用该计划。
我通过先从Web应用程序执行一个测试查询，然后从Management Studio中执行一个测试查询来进行测试，SET ARITHABORT OFF并且可以看到以下查询中的使用量增加了。
SELECT usecounts, cacheobjtype, objtype, text ,query_plan
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 为了使此共享pf计划真正发生，所有计划缓存键必须相同。除arithabort其他示例外，执行用户还需要相同的默认架构（如果查询依赖于隐式名称解析），而连接也需要相同的language集合。
我知道我参加这个聚会很晚，但是对于将来的来访者，马丁是完全正确的。我们遇到了同样的问题-.NET客户端的SP运行非常缓慢，而SSMS却很快。在探索和解决问题时，我们进行了肯尼·埃维特（Kenny Evitt）在评论马丁的问题时所要求的系统测试。
使用马丁查询的一种变体，我在过程缓存中查找了SP，并找到了其中的两个。从计划看，实际上是一个人开了阿里巴特，一个人关了阿里巴特。ARITHABORT OFF版本使用索引搜索，而ARITHABORT ON版本使用相同输出的索引扫描。给定所涉及的参数，索引查找将需要在数千万条记录中查找输出。
我从缓存中清除了两个过程，并让.NET客户端再次使用相同的参数运行SP（对于具有大量活动的客户而言，日期范围宽）。SP立即返回。缓存的计划使用了以前在ARITHABORT ON计划中使用的索引扫描，但是这次计划是用于ARITHABORT OFF的。我们在SSMS中使用相同的参数运行了SP，然后再次立即获得了结果。现在，我们看到使用索引扫描为ARITHABORT ON缓存了第二个计划。
然后，我们清除了缓存，以较小的日期范围在SSMS中运行了SP，并获得了即时结果。我们发现，生成的缓存计划具有索引查找，因为先前使用扫描处理了相同的输出（在原始计划中，这也是ARITHABORT OFF的查找）。再次从SSMS，我们以相同的宽日期范围运行了SP，并且看到了与原始.NET请求中相同的性能。
简而言之，差异与ARITHABORT的实际值无关-无论从哪个客户端打开或关闭ARITHABORT，我们都可以得到可接受或可怕的性能：唯一重要的是用于编译和缓存计划的参数值。
尽管MSDN指出ARITHABORT OFF本身可能会对查询优化产生负面影响，但我们的测试证实Martin是正确的-原因是参数嗅探，并且生成的计划并非对所有参数范围都是最佳的。
Setting ARITHABORT to OFF can negatively impact query optimization leading to performance issues.是什么意思。他们是在谈论无法在计算的列和视图上使用索引（如果ANSI_WARNINGS也处于关闭状态）还是确实有其他影响。
刚遇到这个问题。正如人们在这里所说的，根本原因是多个查询计划，其中之一是次优的。我只是想验证ARITHABORT确实可以单独导致问题（因为查询中我遇到了没有参数的问题，这使参数嗅探不受影响）。
这使我想起了我在sql server 2008天内遇到的完全相同的问题。在我们的例子中，我们突然发现一个sql作业突然变慢了（通常是几秒钟，现在是9分钟以上），该作业需要访问链接服务器，我们在作业的步骤中添加了ARITHABORT设置，这似乎是问题所在解决了几天，然后返回。
后来，我们在MS支持下打开了一个故障单，最初他们都找不到，并且故障单已升级为一支非常高级的PFE团队，并且有两名支持PFE试图解决此问题。
最终原因是（运行作业步骤的）用户凭据无法访问（在链接的服务器端）基础表的统计信息，因此执行计划没有得到优化。
详细地，用户没有DBCC SHOW_STATISTICS的权限（尽管用户可以从表中进行SELECT）。根据MSDN，此权限规则在sql 2012 SP1之后更改
SQL Server和SQL数据库的权限
为了查看统计信息对象，用户必须拥有表，或者用户必须是sysadmin固定服务器角色，db_owner固定数据库角色或db_ddladmin固定数据库角色的成员。
SQL Server 2012 SP1修改了权限限制，并允许具有SELECT权限的用户使用此命令。请注意，存在以下要求，SELECT权限足以运行该命令：
要验证此问题，我们只需要在链接的服务器端实例上运行事件探查器，然后打开“错误和警告”部分中的某些事件，如下所示。
希望这种经验可以以某种方式对社区有所帮助。