.Net 应用程序使用低效查询计划 - 由 ARITHABORT 设置引起？

Question

我们的一个应用程序导致了一个问题，因为有一个存储过程在 SSMS 中返回正常，不到 1 秒，但在应用程序中，它最多需要 10 分钟，具体取决于使用的参数。任何参数组合在 SSMS 中都可以正常工作，执行计划对我来说看起来不错。

然而，当分析应用程序时，显然使用了不同的、效率较低的计划。用于连接的 SqlClient 具有 ARITHABORT 设置，设置为 OFF，当在 SSMS 中复制时，我遇到了相同的性能问题。

我猜 ARITHABORT OFF 将不允许优化器使用缓存计划？或者它运行一个单独的计划？

根据应用程序人员的说法，无法更改 SQLClient 连接以使用 ARITHABORT ON

我猜这里的 ARITHABORT 设置有点用词不当，它实际上是优化器没有使用好的计划导致的参数嗅探？

无论如何，我都需要强制它使用一个好的计划，那么如何最好地解决这个问题呢？我是否以某种方式创建计划指南或优化存储过程？

这是 SQL Server 2008R2 SP2。

Answer 1

您可能会遇到参数嗅探问题。使用不同的ARITHABORT设置执行查询这一事实会使 SQL Server 创建一个新计划，而不是重用现有计划，因为该设置是缓存键的一部分。

看看应用程序中的Slow ， SSMS 中的 fast，它有很多信息，例如：

我们已经看到有大量不同的缓存键，因此单个存储过程可能有很多计划。但我们还了解到，许多作为缓存键的 SET 选项是您永远不应更改的遗留选项。

实际上，最重要的 SET 选项是 ARITHABORT，因为此选项的默认值在应用程序和 SQL Server Management Studio 中是不同的。这解释了为什么您可以在应用程序中发现一个缓慢的查询，然后在 SSMS 中以良好的速度运行它。该应用程序使用的计划是针对一组与实际值不同的嗅探参数值而编译的，而当您在 SSMS 中运行查询时，缓存中可能没有 ARITHABORT ON 计划，因此 SQL Server 将构建适合您当前参数值的计划。

如果您可以更改存储过程，我会尝试在那里修复它，而不是使用计划指南。链接文章中也解释了可能的解决方案，但基本上您有以下选择：

1. 选项（重新编译）/重新编译
2. 添加“最优”索引
3. 删除您不希望计划使用的索引
4. 使用索引提示强制使用任何其他索引。
5. 查询提示 OPTIMIZE FOR。
6. 将参数复制到局部变量。
7. 更改应用程序行为。