前言

　　應用系統承載著大量的業務，隨之而來的是複雜的業務邏輯，在資料庫上的表現就是有著大量的不同種類的SQL語句。

　　SQL語句執行的快慢又與阻塞等待有著密不可分的原因。

　　系統慢可能有很多種原因，硬體資源不足，語句不最佳化，結構設計不合理，缺少必要的運維方式。所有的這些問題都可以在阻塞與等待中看出端倪，發現並解決問題。

　　今天這篇我們主要講述怎麼樣發現並解決系統的阻塞和等待。

場景描述

　　您的系統是否有這樣的問題？

      1.系統執行緩慢，很多功能需要幾十秒才能呈現結果，使用者體驗極差，領導們不斷施壓，作為系統的負責人，只知道系統慢又不知道慢在哪裡？我們遲遲不能解決問題，領導已經對我們怨聲載道了或者已經慢習慣了，不再反饋了。

     2.系統的功能執行緩慢，在生產環境中語句執行時間很長，但是在測試環境或者單獨拿出這條語句執行的卻很快？這好像不科學呀？

    3.我對資料有較多的瞭解，我能查出系統的等待，但是我不知道這些等待意味著什麼，百度的答案五花八門解決不了我的問題。

    4.我能找到等待，也能解決這部分等待，但只是透過一些指令碼，不能全面瞭解現狀，只能東一錘子西一棒子的游擊戰。

    5.我是專家問題我都能解決，但不能給領導一個直觀的展現。

系統等待簡介

　　一個好的SQL語句就好比一輛時速180的好車，好的系統硬體（CPU，記憶體，磁碟）就好比平坦寬闊的馬路。看似好車配好路，一定可以開的很快了！其實還忽略了一點！當你駕駛一輛法拉利跑在北京寬闊的三環上，就算你是老炮中的“三環十二少“， 早高峰你能開到多少? 北京的早高峰！北京的早高峰！

　　這個例子就引出了系統阻塞和等待的概念，紅燈（硬體等待，如IO等待），這就是正常的等待。另外一輛車在你前面不走了或開的很慢，那麼你也只能等待（也可以說成你被他阻塞了）！

　　一張圖告訴你係統的主要等待型別及解決思路：

　　

問題診斷

　　任何問題的診斷都要從全域性的角度考慮，最忌諱的就是看到一個指標高就冒然定位問題，然後以偏概全的去分析問題。

　　一個問題點可能涉及到很多部分，所以我們首先要從全域性的角度定位系統問題，阻塞也是一樣，到底系統中存在哪些型別的阻塞，哪些是主因，哪些是關聯原因，哪些是次要的。

全域性定位阻塞與等待　　

　　首先我們要關心資料庫中有哪些等待型別

　　

　　 注：這部分呈現的是系統中的等待情況，和使用指令碼類似，已經排除了不必要關心的型別，同時對等待情況進行歸類統計。

　　橫座標：等待型別

　　縱座標：收集時間段內出現的次數

　　

　　知道了等到型別，我們要了解這些型別中，哪種佔用了大量的時間：

　　

　　 注：各種等待型別所等待的時間也是排查的主要方向，結合等待型別與等待時間，我們能瞭解到：系統中有哪些等待，哪些等待比較嚴重，哪個最嚴重。

　　橫座標：等待型別

　　縱座標：平均等待時間

　　

　　瞭解了主要的等待型別和時間，我們還要分析一下：什麼資料庫來的？哪些程式來的？什麼使用者請求導致的？什麼時間阻塞最嚴重？

　　

　　

　　

具體語句看等待 

　　系統的整體等待情況瞭然於心，下面我們改看看具體哪些語句造成的等待，這也是解決問題的重要分析步驟。

　　哪些語類句等待最頻繁

　　 注：這裡我們可以根據等待次數、等待時間、消耗的各種資源排序，來多維度分析阻塞的語句型別

　　

　　語句具體的等待情況時怎樣的呢？我們可以透過【原始檢視】檢視具體語句在執行過程中的真實阻塞情況

　　 注：在阻塞的詳細檢視中我們可以清晰的看到語句的阻塞樹，並且可以看到阻塞的語句、時間、資源已經阻塞等待的型別

　　 阻塞樹：本例中【會話68】被【會話66】阻塞，而【會話66】又被【會話104】阻塞，這樣3個會話就構成了一個阻塞鏈也叫阻塞樹

　　

 診斷結論

　　透過全域性定位，語句型別分析，到具體的語句執行阻塞狀態，根據阻塞型別、次數、時間、連線程式、資源消耗等多種維度綜合分析，我們可以清楚的看出資料庫中的阻塞問題。

　　本例中系統主要的阻塞型別為CXPACKET和LCK_M_U，阻塞時間很長，主要的阻塞產生時間為上午十一點左右，主要的阻塞語句是一條update 和一個複雜的select查詢等資訊。

問題解決

　　首先下面的這張圖已經簡單的說明了系統對應的等待需要怎麼樣的解決思路。　　

　　

　　 注：根據不同的情況降低阻塞的辦法主要有：調整伺服器、例項、資料庫配置引數（如：調整並行度），更改隔離級別（如：快照讀，nolock等），最佳化語句（如：新增索引，最佳化寫法等）

　　本例中主要的CXPACKET是因為例項並行度引數配置不佳而導致，LCK_M_U主要是一條update被一個批處理的另一條update阻塞鎖導致，最佳化update這類更新語句主要是保證update語句最最佳化，執行時間儘量縮短，另外高併發下的update比較常見的解決辦法是使用索引利用key鎖取代表鎖以提高併發，可能被更新的表只有幾十條記錄，新增索引與不加索引的併發效率差別也會很大。另外程式的設計也是非常重要的，各種奧秘各位看官只能在實際環境中慢慢體會了，而使用SQL專家雲工具的主要目的在於全面的定位問題，圖表統計等形式清晰的展現問題，並根據工具提供的解決方案快速解決問題。

　　如果是想學習的看官也可以在體檢的【檢查項】及平臺的幫助中瞭解更多的知識和更完善的思路，同時也可以拿著這份“電子病歷”和更多人交流學習。