SQL性能優化之定位網絡性能問題的方法(DEMO)

這篇文章主要介紹了SQL性能優化之定位網絡性能問題的方法的相關資料,需要的朋友可以參考下

最近項目組同事跟我說遇到一個SQL性能問題，他說全表只有69條記錄，客戶端執行耗費了兩分多鐘，很不科學。我幫了分析出了原因並得到解決。下面小編安裝類似表結構，構造了一個案例，測試截圖如下所示：

這個表有13800KB（也就是13M多大小），因為該表將圖片保存到數據庫（Item_Photo字段為iamge類型），這個是歷史原因，暫且不噴這種的設計。看來這個SQL執行時間長的性能問題不在於IO和SQL本身執行計劃是否有問題，而是在網絡數據傳時間上（服務器與客戶端位於異地，兩地專線帶寬6M，不過很多應用、郵件、系統都依賴此專線）

sp_spaceused 'Item_Test' name rows reserved data index_size unused----------- ------------- ---------- -------------- ----------- -------------Item_Test 69 13864 KB 13800 KB 16 KB 48 KB 

為了驗證我的想法，我在服務器本機測試時間為2秒，如下截圖所示

從上面我們知道在客戶端執行完該SQL語句，總共耗費了2分23秒。那麼客戶端的到底獲取了多少字節數據，數據傳輸耗費了多長時間呢？ 能否查看這些DETAIL信息呢？ 答案是可以。在SSMS工具欄，勾選“Include Client Statistics”或使用快捷鍵SHIFT+ALT+S，然後執行SQL語句，就能得到如下截圖的相關信息。

Client Statistics(客戶端統計信息）包含三大塊： Query Profile Statistics， Network Statistics, Time Statistics。
這些部分的內容很容易理解，無需多說，那麼我們來看看吧

Network Statistics（網絡統計信息） Number of server roundtrips: 服務器往返的次數 TDS packets sent from client: 從客戶端發送的TDS數據包（個數） TDS packets received from server: 從服務端接收的TDS數據包（個數） Bytes sent from client: 從客戶端發送的字節數 Bytes received from server: 從服務器接收的字節數 Time Stattistics:（時間統計信息） Client processing time: 客戶端處理時間 Total execution time: 總執行時間 Wait time on server replies: 服務器應答等待時間

從客戶端發送的字節和從服務端接收的數據大小都很清晰、明了，那麼數據從服務器端發送給客戶端所需的時間這裡沒有，其實它基本上接近客戶端處理時間（Client processing time），我們也可以將客戶端處理時間權當網絡數據傳輸時間，從上面案例，我們可以看到這個時間耗費了140秒（140132 ms）,可以肯定這個SQL性能慢在網絡數據傳輸上，而不是慢在數據庫那一塊（Server Processing Time）.

我們來看看下圖，這個是SQL SERVER的請求接收和數據輸出的一個大致流程圖，當客戶端發送請求開始，當服務器接收客戶端發來的最後一個TDS包，數據庫引擎開始處理請求，請求完成後，將數據發送給客戶端，從圖中可以看出，客戶端接收服務器端返回的數據也是需要一個過程的（或者說時間）

我們在SQL優化過程中，如果一個SQL出現性能問題時，我們應該站在一個全局的角度來分析問題，從CPU資源、網絡帶寬、磁盤IO、執行計劃等多方面來分析，這樣才能有助於你分析、定位問題根源，而不要只要SQL響應很慢時，就一味條件反射式先入為主：這是數據庫問題。數據庫也不能老背這個黑鍋。

在數據庫等待事件中，ASYNC_NETWORK_IO可以從另外一個側面反映網絡性能問題。關於ASYNC_NETWORK_IO等待類型：

This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application.

那麼回到如何優化這個SQL的問題上來，我們可以從下面幾個方面來進行優化。

1： SQL只取必須的字段數據

像這個案例，其實它根本不需要Item_Photo字段數據，那麼我們可以修改SQL，只取我們需要的字段數據，就可以避免這個問題，提高SQL性能，另外根據我的經驗，開發人員習慣性使用SELECT *，從不管那些數據是需要還是不需要的，先全部取過來再說，這種習慣性行為確實不是一個好習慣。

2：避免這種腦殘設計

圖片應該以文件形式保存在應用服務器上，數據庫只保存其路徑信息，這種將圖片保存到數據庫的設計純屬腦殘行為。

以上所述是小編通過一個小demo給大家介紹的SQL性能優化之定位網絡性能問題的方法，希望對大家有所幫助！