阻塞的常見原因和解決辦法：
1. 由於語句已耗用時間太長而導致的阻塞，語句本身在正常運行中，只須等待某些系統資源
解決辦法：
a. 語句本身有沒有可最佳化的空間b. Sql Server 整體效能如何，是不是有資源瓶頸影響了語句執行速度，如 記憶體、硬碟 和 CPU 等
2. 由於一個未按預期提交的事務導致的阻塞
這一類阻塞的特徵，就是問題串連早就進入了空閑狀態(sysprocesses.status='sleeping'和sysprocesses.cms='awaiting command')，但是，如果檢查 sysprocesses.open_tran,就會發現它不為0，以及事務沒有提交。這類問題很多都是因為應用端遇到了一個執行逾時，或者其他原因，當時執行的語句倍提前終止了，但是串連還保留著。應用沒有跟隨發來的事務提交或復原指令，導致一個事務被遺留在 Sql Server 裡。
解決辦法：
應用程式本身必須意識到任何語句都有可能遇到意外終止的情況，做好錯誤處理工作。這些工作包括：
· 在做 Sql Server 調用的時候，須加上錯誤捕捉和處理語句：If @@Trancount>0 RollBack Tran;(在程式中設定If @@Error<>0 Rollback Tran; 並不總是能執行到該語句)· 設定串連屬性"Set XACT_ABORT ON"。如果沒有辦法很規範應用程式的錯誤撲捉和處理語句，一個最快的方法就是在每個串連建立以後，或是容易出問題的預存程序開頭，運行 "Set XACT_ABORT ON"·考慮是否要關閉串連池。發一句 sp_reset_connection 命令清理當前串連上次遺留下來的所有對象，包括復原未提交的事務。
3. 由於用戶端沒有及時把結果集取出而導致的語句長時間運行
語句在 Sql Server 內執行總時間不僅包含 Sql Server 的執行時間，還包含把結果集發給用戶端的時間。如果結果集比較大，Sql Server 會分幾次打包發出，沒發一次，都要等待用戶端的確認。只有確認以後，Sql Server 才會發送下一個結果集包。所有結果都發完以後，Sql Server才認為語句執行完畢，釋放執行申請的資源（包括鎖資源）。如果出於某種原因，用戶端應用處理結果非常緩慢甚至沒有響應，或者乾脆不理睬 Sql Server 發送結果集的請求，則 Sql Server 會耐心的等待，銀次會導致語句長時間執行而產生阻塞。 解決辦法： a. 謹慎返回大結果集b. 如果a短期內不能實現，則嘗試大結果集的串連使用 Read Uncommitted 交易隔離等級,這樣查詢就不會申請 S 鎖了
4. 阻塞的源頭一直處於 RollBack 狀態
這種情況是由第一類情況衍生來的。有時候發現一個串連阻塞住了別人，為瞭解決問題，直接讓串連主動退出或強制退出(直接 Kill 串連)。對於大部分情況，這些措施會消除阻塞。但是也有例外。在串連退出的時間，為了維護資料庫事務的一致性， Sql Server都會對串連還沒有來得及完成提交的事務做復原動作。Sql Server要找到所有當前事務修改過的記錄，把它們改回原來的狀態。所以，如果一個 Delete、Insert 或 Update 運行了1個小時，可能復原也需要一個小時。 有些使用者可能等不及，直接重啟 Sql Server。當 Sql Server 關閉的時候，復原動作會被中斷，Sql Server 會被很快關掉。但是這個復原動作在下次 Sql Server 重啟的時候會重新開始。重啟的時候如果復原不能很快結束，整個資料庫都會不可用。
解決辦法：
最好的方法是在工作時間盡量不要做這種大的修改操作。這些操作要盡量安排在半夜或周末的時間完成。如果操作已經進行了很久，最好耐心等它做完。如果一定要在有工作負載的時候做，最好把一個大操作分成若干小操作分布完成
5. 應用程式中產生死結
相關文章：Sql Server 鎖資源模式詳解sql server 2008 R2 串連數過高的解決辦法利用 sys.sysprocesses 檢查 Sql Server的阻塞和死結 本文首發於部落格園 ：Sql Server 阻塞的常見原因和解決辦法
