一同事跟我反饋他遇到了一個SQL性能問題，他說全表只有69條記錄，客戶端執(zhí)行耗費了兩分多鐘，這不科學(xué)呀。要我分析一下原因并解決。我按照類似表結(jié)構(gòu)，構(gòu)造了一個案例，測試截圖如下所示

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

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

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

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

Client Statistics(客戶端統(tǒng)計信息)包含三大塊：? Query Profile Statistics， Network Statistics, Time Statistics。

這些部分的內(nèi)容很容易理解，無需多說，那么我們來看看吧

Network?Statistics(網(wǎng)絡(luò)統(tǒng)計信息) ? ? Number?of?server?roundtrips:????????服務(wù)器往返的次數(shù) ? TDS?packets?sent?from?client:???????從客戶端發(fā)送的TDS數(shù)據(jù)包(個數(shù)) ? TDS?packets?received?from?server:???從服務(wù)端接收的TDS數(shù)據(jù)包(個數(shù)) ? Bytes?sent?from?client:?????????????從客戶端發(fā)送的字節(jié)數(shù) ? Bytes?received?from?server:?????????從服務(wù)器接收的字節(jié)數(shù) ? ? ? Time?Stattistics:(時間統(tǒng)計信息) ? ? Client?processing?time:??????????????客戶端處理時間 ? Total?execution?time:????????????????總執(zhí)行時間 ? Wait?time?on?server?replies:?????????服務(wù)器應(yīng)答等待時間

從客戶端發(fā)送的字節(jié)和從服務(wù)端接收的數(shù)據(jù)大小都很清晰、明了，那么數(shù)據(jù)從服務(wù)器端發(fā)送給客戶端所需的時間這里沒有，其實它基本上接近客戶端處理時間(Client processing time)，我們也可以將客戶端處理時間權(quán)當(dāng)網(wǎng)絡(luò)數(shù)據(jù)傳輸時間，從上面案例，我們可以看到這個時間耗費了140秒(140132 ms),可以肯定這個SQL性能慢在網(wǎng)絡(luò)數(shù)據(jù)傳輸上，而不是慢在數(shù)據(jù)庫那一塊(Server Processing Time).

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

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

在數(shù)據(jù)庫等待事件中，ASYNC_NETWORK_IO可以從另外一個側(cè)面反映網(wǎng)絡(luò)性能問題。關(guān)于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.

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

???1： SQL只取必須的字段數(shù)據(jù)

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

???2：避免這種腦殘設(shè)計

????? 圖片應(yīng)該以文件形式保存在應(yīng)用服務(wù)器上，數(shù)據(jù)庫只保存其路徑信息，這種將圖片保存到數(shù)據(jù)庫的設(shè)計純屬腦殘行為。

參考資料：

https://www.simple-talk.com/sql/database-administration/how-come-the-hourglass-why-database-applications-slow-down.-/

總結(jié)

以上是生活随笔為你收集整理的SQL性能优化：如何定位网络性能问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。