應用系統承載著大量的業務，隨之而來的是複雜的業務邏輯，在資料庫上的表現就是有著大量的不同種類的sql語句。
sql語句執行的快慢又與阻塞等待有著密不可分的原因。
系統慢可能有很多種原因，硬體資源不足，語句不優化，結構設計不合理，缺少必要的運維方式。所有的這些問題都可以在阻塞與等待中看出端倪，發現並解決問題。
今天這篇我們主要講述怎麼樣發現並解決系統的阻塞和等待。
您的系統是否有這樣的問題？
系統執行緩慢，很多功能需要幾十秒才能呈現結果，使用者體驗極差，領導們不斷施壓，作為系統的負責人，只知道系統慢又不知道慢在**？我們遲遲不能解決問題，領導已經對我們怨聲載道了或者已經慢習慣了，不再反饋了。
系統的功能執行緩慢，在生產環境中語句執行時間很長，但是在測試環境或者單獨拿出這條語句執行的卻很快？這好像不科學呀？
我能找到等待，也能解決這部分等待，但只是通過一些指令碼，不能全面了解現狀，只能東一錘子西一棒子的游擊戰。
我是專家問題我都能解決，但不能給領導乙個直觀的展現。
這個例子就引出了系統阻塞和等待的概念，紅燈（硬體等待，如io等待），這就是正常的等待。另外一輛車在你前面不走了或開的很慢，那麼你也只能等待（也可以說成你被他阻塞了）！
一張圖告訴你系統的主要等待型別及解決思路：
任何問題的診斷都要從全域性的角度考慮，最忌諱的就是看到乙個指標高就冒然定位問題，然後以偏概全的去分析問題。
乙個問題點可能涉及到很多部分，所以我們首先要從全域性的角度定位系統問題，阻塞也是一樣，到底系統中存在哪些型別的阻塞，哪些是主因，哪些是關聯原因，哪些是次要的。
首先我們要關心資料庫中有哪些等待型別
了解了主要的等待型別和時間，我們還要分析一下：什麼資料庫來的？哪些程式來的？什麼使用者請求導致的？什麼時間阻塞最嚴重？
系統的整體等待情況了然於心，下面我們改看看具體哪些語句造成的等待，這也是解決問題的重要分析步驟。
哪些語類句等待最頻繁
語句具體的等待情況時怎樣的呢？我們可以通過【原始檢視】檢視具體語句在執行過程中的真實阻塞情況
通過全域性定位，語句型別分析，到具體的語句執行阻塞狀態，根據阻塞型別、次數、時間、連線程式、資源消耗等多種維度綜合分析，我們可以清楚的看出資料庫中的阻塞問題。
本例中系統主要的阻塞型別為cxpacket和lck_m_u，阻塞時間很長，主要的阻塞產生時間為上午十一點左右，主要的阻塞語句是一條update 和乙個複雜的select查詢等資訊。
首先下面的這張圖已經簡單的說明了系統對應的等待需要怎麼樣的解決思路。
sqlserver死鎖阻塞
create proc p lockinfo kill lock spid bit 1,是否殺掉死鎖的程序,1 殺掉,0 僅顯示 show spid if nolock bit 1 如果沒有死鎖的程序,是否顯示正常程序資訊,1 顯示,0 不顯示 as declare count int,s nvar...
sql server 阻塞查詢
原文 sql server 阻塞查詢 在生產環境下，有時公司客服反映網頁半天打不到，除了在瀏覽器按f12的network響應來排查，確定web伺服器無故障後。就需要檢查資料庫是否有出現阻塞 當時資料庫的生產環境中主表資料量超過2000w,子表資料量超過1億，且更新和新增頻繁。再加上做了同步映象，很消...
SQL Server的阻塞 死鎖問題
通過 sysprocesses 簡單查詢死鎖及解決死鎖辦法 簡單查詢死鎖，如下四步可以輕鬆解決 第一步 查詢死鎖語句 1 條件是 blocked 0 select dbid,from sys.sysprocesses where 1 1 and spid 50 and blocked 0 and s...