基于不同的客户端与sql server进行通信的不同结果

Question

我的生产系统中有一个非常奇怪的情况出现在今天的工作中。想知道是否有人看到过这样的东西，对我有很好的解释。

我们在Sql Server 2014中有一个存储过程，当我们的.NET系统调用它时，它并没有返回任何数据。

我们使用Sql Profiler捕获了调用，并在Sql Management Studio中使用相同的Sql Authentication凭据重播它，并且它按照预期返回结果。

无论我们互换地尝试过多少次，它们都是一致的，因为当客户端是.NET客户端时，它没有给出任何结果，并且当它是SSMS时它工作正常。请记住，它完全相同的sp，params等。

我们通过执行SP重新编译来解决问题，但感觉像是临时解决方案，不知道原始原因意味着它可以在不发出警告的情况下重新发生。此外，我的印象是，sp重新编译只会影响性能问题，而不会影响结果。

有没有人见过这个？你能解释为什么一个sp重新编译修复它吗？

非常感谢！

Answer 1

通常情况下，你会发现查询将在SSMS中执行得很好，但是.Net客户端会超时。这可能是你在这里描述的。

关于此问题的确切原因存在一些争议。

一方面，问题在于SSMS和.Net客户端具有不同的默认值。最常见的罪犯ARITHABORT，这SSMS设置为开启状态，但大多数SQL服务器供应商在服务器保留默认值（OFF）：

警告

默认ARITHABORT设置为SQL Server Management Studio中为ON 。 将ARITHABORT设置为OFF的客户端应用程序可能会收到不同的 查询计划，从而难以排查表现不佳的 查询。也就是说，相同的查询可以在管理工作室 中快速执行，但在应用程序中速度较慢。使用 排除疑难解答时，Management Studio始终与客户端ARITHABORT设置匹配。

这导致a cached query plan（一个相当复杂的主题），在SSMS中运行良好，但在.Net客户端不太好。

另一方面，问题只是parameter sniffing，这意味着您的存储过程有一个错误的缓存计划。这方认为ARITHABORT设置会导致服务器选择一个不同的计划，跳过不好的计划。但核心问题是参数嗅探，而ARITHABORT设置实际上是一种解决方法。 （设置ARITHABORT ON，使用OPTION RECOMPILE，使用OPTIMIZE FOR UNKNOWN等）。这些解决方案涵盖了许多可能的解决方案。这个问题也与Erland Sommarskog的开创性工作Slow in the Application, Fast in SSMS?: Understanding Performance Mysteries有关，这可能比你以前想知道的要多。