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 重啟的時候會重新開始。重啟的時候如果回滾不能很快結束，整個數據庫都會不可用。
解決辦法：
最好的方法是在工作時間盡量不要做這種大的修改操作。這些操作要盡量安排在半夜或周末的時間完成。如果操作已經進行了很久，最好耐心等它做完。如果一定要在有工作負荷的時候做，最好把一個大操作分成若干小操作分布完成
1 -- 查詢死鎖 2 select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName 3 from sys.dm_tran_locks 4 where resource_type='OBJECT' 5 6 --查詢主機名等信息 7 exec sp_who2 238 8 9 --殺死死鎖進程 10 kill 238