婷婷综合国产,91蜜桃婷婷狠狠久久综合9色 ,九九九九九精品,国产综合av

主頁 > 知識庫 > SQL性能優化之定位網絡性能問題的方法(DEMO)

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

熱門標簽:地圖標注可以編輯地名嗎 樂昌電話機器人 南通智能外呼系統怎么樣 南京怎么申請400這種電話 真3地圖標注 臺灣外呼系統軟件 地圖標注跑線下市場 疫情時期電話機器人 濮陽清豐400開頭的電話申請

最近項目組同事跟我說遇到一個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性能優化之定位網絡性能問題的方法,希望對大家有所幫助!

您可能感興趣的文章:
  • MySQL性能優化的一些技巧幫助你的數據庫
  • MySQL性能優化
  • mysql性能優化腳本mysqltuner.pl使用介紹
  • MySQL DBA教程:Mysql性能優化之緩存參數優化
  • MySQL性能優化之路---修改配置文件my.cnf
  • MySQL性能優化配置參數之thread_cache和table_cache詳解
  • MySQL性能優化之max_connections配置參數淺析
  • MySQL性能優化之table_cache配置參數淺析
  • MySQL性能優化之Open_Table配置參數的合理配置建議
  • php導入大量數據到mysql性能優化技巧

標簽:廣安 河北 南京 通遼 陜西 阿里 馬鞍山 福建

巨人網絡通訊聲明:本文標題《SQL性能優化之定位網絡性能問題的方法(DEMO)》,本文關鍵詞  SQL,性能,優化,之,定位,網絡,;如發現本文內容存在版權問題,煩請提供相關信息告之我們,我們將及時溝通與處理。本站內容系統采集于網絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《SQL性能優化之定位網絡性能問題的方法(DEMO)》相關的同類信息!
  • 本頁收集關于SQL性能優化之定位網絡性能問題的方法(DEMO)的相關信息資訊供網民參考!
  • 推薦文章
    主站蜘蛛池模板: 江都市| 安远县| 抚远县| 澎湖县| 百色市| 北安市| 嵊州市| 巴彦淖尔市| 北辰区| 黄大仙区| 区。| 河曲县| 崇文区| 海淀区| 东安县| 杭锦后旗| 忻州市| 锦州市| 屯门区| 大名县| 罗源县| 普陀区| 浑源县| 江川县| 江城| 禄丰县| 久治县| 眉山市| 景宁| 丰都县| 盐山县| 绥阳县| 寿阳县| 怀柔区| 革吉县| 郸城县| 芦溪县| 河南省| 建湖县| 南平市| 星座|