今天在我们的生产系统中发生了一个非常奇怪的场景。想知道有没有人看到过这样的事情并给我一个很好的解释。
我们在 Sql Server 2014 中有一个存储过程，当我们的 .NET 系统调用它时它没有返回任何数据。
我们使用 Sql Profiler 捕获了调用，并使用相同的 Sql 身份验证凭据在 Sql Management Studio 中重放了它，它返回了预期的结果。
无论我们交替尝试了多少次，它们都是一致的，当客户端是 .NET 客户端时，它没有给出任何结果，而当它是 SSMS 时，它工作正常。请记住，它的 sp、params 等完全相同。
我们能够通过执行 SP 重新编译来解决问题，但这感觉像是一个临时解决方案，并且不知道最初的原因意味着它可以在没有警告的情况下再次发生。此外，我的印象是 sp 重新编译只影响性能问题而不影响结果。
有人见过这个吗？你能解释为什么 sp 重新编译修复它吗？
非常感谢！
【问题讨论】：
标签： sql-server-2014
通常您会看到查询在 SSMS 中执行得很好，但在 .Net 客户端中会超时。这可能就是您在此处描述的内容。
关于这个问题的确切原因存在一些争论。
一方面，问题在于 SSMS 和 .Net 客户端具有不同的默认值。最常见的违规者是ARITHABORT，SSMS 设置为 ON，但大多数 SQL Server 提供程序保留服务器默认值 (OFF)：
警告
SQL Server Management Studio 的默认 ARITHABORT 设置为开启。 将 ARITHABORT 设置为 OFF 的客户端应用程序可以接收不同的 查询计划使得难以解决性能不佳的问题 查询。也就是说，同样的查询可以在management studio中快速执行 但应用速度慢。在对查询进行故障排除时 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 相关联，这可能比你想知道的更多。
【讨论】：