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 鎖了