當來自應用程序的第一個連接控制鎖而第二個連接需要相沖突的鎖類型時，將發生阻塞。其結果是強制第二個連接等待，而在第一個連接上阻塞。不管是來自同一應用程序還是另外一台客戶機上單獨的應用程序，一個連接都可以阻塞另一個連接。
說明一些需要鎖保護的操作可能不明顯，例如系統目錄表和索引上的鎖。
大多數阻塞問題的發生是因為一個進程控制鎖的時間過長，導致阻塞的進程鏈都在其它進程上等待鎖。
常見的阻塞情形包括：
◆提交執行時間長的查詢。
長時間運行的查詢會阻塞其它查詢。例如，影響很多行的delete或update操作能獲取很多鎖，這些鎖不論是否升級到表鎖都阻塞其它查詢。因此，一般不要將長時間運行的決策支持查詢和聯機事務處理 (OLTP)查詢混在一起。解決方案是想辦法優化查詢，如更改索引、將大的復雜查詢分成簡單的查詢或在空閒時間或單獨的計算機上運行查詢。
查詢運行時間長並由此導致阻塞的一個原因是這些查詢不適當地使用游標。游標可能是在結果集中浏覽的便利方法，但使用游標可能比使用面向集合的查詢慢。
◆取消沒有提交或回滾的查詢。
如果應用程序取消查詢(如使用開放式數據庫連接(ODBC) sqlcancel 函數)但沒有同時發出所需數目的ROLLBACK和COMMIT語句，則會發生這種情況。取消查詢並不自動回滾或提交事務。取消查詢後，所有在事務內獲取的鎖都將保留。應用程序必須提交或回滾已取消的事務，從而正確地管理事務嵌套級。
◆應用程序沒處理完所有結果。
將查詢發送到服務器後，所有應用程序必須立即完成提取所有結果行。如果應用程序沒有提取所有結果行，鎖可能會留在表上而阻塞其他用戶。如果使用的應用程序將 Transact-SQL 語句透明地提交給服務器，則該應用程序必須提取所有結果行。如果應用程序沒這樣做(如果無法配置它執行此操作)，則可能無法解決阻塞問題。為避免此問題，可以將這些應用程序限制在報表或決策支持數據庫上。
