SQL機能優化之定位收集機能成績的辦法(DEMO)。本站提示廣大學習愛好者：（SQL機能優化之定位收集機能成績的辦法(DEMO)）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL機能優化之定位收集機能成績的辦法(DEMO)正文
比來項目組同事跟我說碰到一個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機能優化之定位收集機能成績的辦法，願望對年夜家有所贊助！
