基於不同的客戶端與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有關，這可能比你以前想知道的要多。