最近項(xiàng)目組同事跟我說遇到一個(gè)SQL性能問題，他說全表只有69條記錄，客戶端執(zhí)行耗費(fèi)了兩分多鐘，很不科學(xué)。我?guī)土朔治龀隽嗽虿⒌玫浇鉀Q。下面小編安裝類似表結(jié)構(gòu)，構(gòu)造了一個(gè)案例，測(cè)試截圖如下所示：

這個(gè)表有13800KB（也就是13M多大?。?，因?yàn)樵摫韺D片保存到數(shù)據(jù)庫（Item_Photo字段為iamge類型），這個(gè)是歷史原因，暫且不噴這種的設(shè)計(jì)?？磥磉@個(gè)SQL執(zhí)行時(shí)間長(zhǎng)的性能問題不在于IO和SQL本身執(zhí)行計(jì)劃是否有問題，而是在網(wǎng)絡(luò)數(shù)據(jù)傳時(shí)間上（服務(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 

為了驗(yàn)證我的想法，我在服務(wù)器本機(jī)測(cè)試時(shí)間為2秒，如下截圖所示

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

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

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

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

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

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

在數(shù)據(jù)庫等待事件中，ASYNC_NETWORK_IO可以從另外一個(gè)側(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)化這個(gè)SQL的問題上來，我們可以從下面幾個(gè)方面來進(jìn)行優(yōu)化。 

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

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

2：避免這種腦殘?jiān)O(shè)計(jì) 

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

以上所述是小編通過一個(gè)小demo給大家介紹的SQL性能優(yōu)化之定位網(wǎng)絡(luò)性能問題的方法，希望對(duì)大家有所幫助！