我今天在我们的生产系统中有一个非常奇怪的情况。想知道是否有人见过这样的事情并且对我有好的解释。
我们在Sql Server 2014中有一个存储过程，当我们的.NET系统调用它时它没有返回任何数据。
我们使用Sql Profiler捕获了该调用，并使用相同的Sql Authentication凭据在Sql Management Studio中重播它，并按预期返回结果。
无论我们互换多少次，它们都是一致的，当客户端是.NET客户端时，它没有给出任何结果，当它是SSMS时，它工作正常。请记住，它与sp，params等完全相同。
我们能够通过执行SP重新编译来解决问题，但这感觉就像一个临时解决方案而且不知道原始原因意味着它可以在没有警告的情况下重复出现。此外，我的印象是sp重新编译只会影响性能问题而不会产生不同的结果。
有没有人见过这个？你能解释为什么sp重新编译修复它吗？
非常感谢！
答案 0 :(得分：1)
通常你看到的是查询将使用SSMS执行得很好，但是对于.Net客户端，它会超时。这可能是你在这里描述的内容。
关于这个问题的确切原因存在争议。
一方面，问题是SSMS和.Net Client有不同的默认值。最常见的攻击者是ARITHABORT，SSMS设置为ON，但大多数SQL Server提供者都在服务器默认设置（OFF）：
警告
SQL Server Management Studio的默认ARITHABORT设置为ON。 将ARITHABORT设置为OFF的客户端应用程序可以接收不同的 查询计划使得难以解决性能不佳的问题 查询。也就是说，相同的查询可以在管理工作室中快速执行 但应用程序速度很慢。使用时查询疑难解答 Management Studio始终与客户端ARITHABORT设置匹配。
这导致a cached query plan（一个相当复杂的主题）在SSMS中运行良好，但在.Net客户端却不太好。
另一方面，问题只是parameter sniffing，这意味着您的存储过程缓存了错误的计划。这一方认为ARITHABORT设置使服务器选择不同的计划，跳过坏的计划。但核心问题是参数嗅探，而ARITHABORT设置实际上是一种解决方法。
This SO question涵盖了许多可能的解决方案（设置ARITHABORT ON，使用OPTION RECOMPILE，使用OPTIMIZE FOR UNKNOWN等）。这个问题也与Erland Sommarskog的Slow in the Application, Fast in SSMS?: Understanding Performance Mysteries的开创性工作有关，这可能比你曾经想知道的更多。