Azure SQL查詢編輯器vs Management Studio

Question

一般而言，我對天青和雲計算還很陌生，想請您幫忙解決問題。

當我們將網頁由於sql超時設置為（30秒）而超時時，首次發現該問題。

我所做的第一件事是使用MS SQL Management Studio 2014連接到生產數據庫（已連接到Azure Prod數據庫）

運行性能低下的頁面正在使用的存儲過程，但返回少於0秒。 這使我感到困惑，因為可能是引起該問題的原因。

偶然地，我也嘗試在Azure SQL查詢編輯器中運行相同的查詢，但震驚的是它花了29秒來運行它。

我的主要問題是，為什么在Azure SQL查詢編輯器中運行查詢與Management Studio之間會有區別？ 這是完全相同的數據庫。

DTU的使用率為98％，並且存儲的過程存在性能問題，但首先想知道為什么sql editor運行SP的速度比Management Studio慢。

當前的天藍色db有50 dtu。

Answer 1

兩個猜想（發布查詢計划將幫助您為此類情況提供答案）：

1. SQL Server具有各種會話級設置。 例如，可以使用一種方法來確定是否應使用ansi_nulls行為（相對於SQL Server的較舊版本中的先前設置）。 還有其他關於如何引用標識符和類似標識符的方法。 由於遺留原因，某些驅動程序具有不同的默認設置。 這些不同的設置可能會影響選擇的查詢計划。 盡管它們並不總是會影響性能，但是您有可能獲得掃描而不是尋找您感興趣的查詢。

2. 解釋此類問題的另一種主要途徑是您有一個參數嗅探差異。 SQL的優化器將窺視用於選擇更好計划的參數值（希望該值代表將來參數值的平均用例）。 Oracle將此稱為綁定窺視-SQL將其稱為參數嗅探。 這是我前一段時間在此發表的帖子，其中包含一些示例： https : //blogs.msdn.microsoft.com/queryoptteam/2006/03/31/i-smell-a-parameter/

我建議您進行實驗，然后查看查詢存儲以查看是否有不同的查詢或不同的計划被選擇。 您可以在此處了解查詢存儲和SSMS UI： https ://docs.microsoft.com/zh-cn/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view = SQL服務器-2017

對於這種特定情況，請注意查詢存儲使用“上下文設置”公開那些不同的會話級設置。 上下文設置的每個唯一組合將顯示為不同的上下文設置id，這將通知如何解釋查詢文本。 用查詢存儲的說法，可以在不同的上下文設置下以不同的方式解釋相同的查詢文本，因此同一查詢文本的兩個不同的上下文設置將意味着兩個語義上不同的查詢。

希望對您有幫助-最好解決您的性能問題