從 SP 語句完成擷取的時間與 RPC 完成的時間相差很大的查詢的性能

從 XE 事件收集數據時，我無法理解以下查詢的性能：

詢問

DECLARE @Importdate DATETIME = ISNULL ((

SELECT ImportDatetime
FROM
Customertable
where CustomerID = 1
and OrderID =1 
) , '01/01/2000')

這部分語句只返回 1 行

SP statement completed顯示40 秒

RPC Completed上述語句顯示64 秒

需要幫助了解為什麼 RPC 會顯示出如此大的差異以及在哪裡尋找這個問題？我沒有看到任何這樣報告的 NW 問題，但這在這裡表明了什麼，並且像上面這樣簡單的查詢對於該執行時間似乎很高

請指教

一般來說rpc_completed 包括網路時間，而 sp_statement_completed 不包括。您的查詢很可能就是這種情況，因為它只返回一行。

所以一種解釋是額外的時間花在了通過網路向客戶端發送數據上。

您可以嘗試測量此查詢的等待統計資訊，以確認有 24 秒的 ASYNC_NETWORK_IO 等待可以解釋差異。

如果伺服器安裝了 SSMS，你可以遠端桌面進入它並在那裡執行查詢，這應該有很少的網路等待時間。在這種情況下，您會發現這兩個事件的時間差異很小。

首先，您聲明：

是的，這是儲存過程中語句的一部分。

這是儲存過程中唯一的語句嗎？雖然如果進行測試並非不可能，但擁有一個設置變數然後從不使用它或做任何其他事情的儲存過程似乎很奇怪。那麼，儲存過程中的其他語句呢？他們所有的時間都計算了嗎？

1. RPC:Starting— 執行過程的遠端過程呼叫（即不是臨時查詢批處理）

2. SP:Starting— 儲存過程啟動（如果它不在記憶體中，將花費時間編譯它）

3. 一組或多組：

4. SP:StmtStarting

5. SP:StmtCompleted

6. SP:Completed

7. RPC:Completed

如果要檢查延遲，請務必擷取EndTime並比較以下值：

• 決賽SP:StmtCompleted和SP:Completed
• SP:Completed和RPC:Completed
• 如果有很多結果行被發回和/或呼叫應用程序沒有足夠快地使用它們，這可能會顯示為 finalSP:StmtCompleted和SP:Completed.

除此以外：

• 編譯時間可能EndTime是ofSP:Starting和StartTimeof first之間的差異SP:StmtStarting。
• 此過程中還有哪些其他語句以及持續時間是多少？

接下來，我們真的在這裡談論秒嗎？給定兩個（或類似）謂詞SELECT的單列40 秒？INT即使沒有索引來幫助我也希望這樣的查詢能在 40 秒之前返回，除非有很多爭用和/或表有數十億行，或類似的東西。您是否有可能除以錯誤的數字？我認為你應該除以1000000。如果這些數字是正確的，那麼我會更關心為什麼這個簡單SELECT的東西會佔用 40 秒，而不是其他任何東西佔用剩下的 24 秒。

引用自：https://dba.stackexchange.com/questions/267556