當來自應用程序的第一個連接控制鎖而第二個連接需要相沖突的鎖類型時，將發生阻塞。其結果是強制第二個連接等待，而在第一個連接上阻塞。不管是來自同一應用程序還是另外一臺客戶機上單獨的應用程序，一個連接都可以阻塞另一個連接。

說明一些需要鎖保護的操作可能不明顯，例如系統目錄表和索引上的鎖。

大多數阻塞問題的發生是因為一個進程控制鎖的時間過長，導致阻塞的進程鏈都在其它進程上等待鎖。

常見的阻塞情形包括：

◆提交執行時間長的查詢。

長時間運行的查詢會阻塞其它查詢。例如，影響很多行的 DELETE 或 UPDATE 操作能獲取很多鎖，這些鎖不論是否升級到表鎖都阻塞其它查詢。因此，一般不要將長時間運行的決策支持查詢和聯機事務處理 (OLTP) 查詢混在一起。解決方案是想辦法優化查詢，如更改索引、將大的復雜查詢分成簡單的查詢或在空閑時間或單獨的計算機上運行查詢。

查詢運行時間長并由此導致阻塞的一個原因是這些查詢不適當地使用游標。游標可能是在結果集中瀏覽的便利方法，但使用游標可能比使用面向集合的查詢慢。

◆取消沒有提交或回滾的查詢。

如果應用程序取消查詢（如使用開放式數據庫連接 (ODBC) sqlcancel 函數）但沒有同時發出所需數目的 ROLLBACK 和 COMMIT 語句，則會發生這種情況。取消查詢并不自動回滾或提交事務。取消查詢后，所有在事務內獲取的鎖都將保留。應用程序必須提交或回滾已取消的事務，從而正確地管理事務嵌套級。

◆應用程序沒處理完所有結果。

將查詢發送到服務器后，所有應用程序必須立即完成提取所有結果行。如果應用程序沒有提取所有結果行，鎖可能會留在表上而阻塞其他用戶。如果使用的應用程序將 Transact-SQL 語句透明地提交給服務器，則該應用程序必須提取所有結果行。如果應用程序沒這樣做（如果無法配置它執行此操作），則可能無法解決阻塞問題。為避免此問題，可以將這些應用程序限制在報表或決策支持數據庫上。

◆分布式客戶端/服務器死鎖。

與常規死鎖不同，分布式死鎖無法由 Microsoft® SQL Server™ 2000 自動檢測到。如果應用程序打開多個與 SQL Server 的連接并異步提交查詢，則可能會發生分布式客戶端/服務器死鎖。

例如，一個客戶端應用程序線程有兩個開放式連接。該線程異步啟動事務并在第一個連接上發出查詢。應用程序隨后啟動其它事務，在另一個連接上發出查詢并等待結果。當 SQL Server 返回其中一個連接的結果時，應用程序開始處理這些結果。應用程序就這樣處理結果，直到生成結果的查詢被另一個連接上執行的查詢阻塞而導致再沒有可用的結果為止。此時第一個連接阻塞，無限期等待處理更多的結果。第二個連接沒有在鎖上阻塞，但仍試圖將結果返回給應用程序。然而，由于應用程序阻塞而在第一個連接上等待結果，第二個連接的結果將得不到處理。

若要避免此問題，請執行下列任一操作：

●對每個查詢使用查詢超時。

●對每個查詢使用鎖定超時。

●使用綁定連接。

SQL Server 本質上是受客戶端應用程序操縱的傀儡?？蛻舳藨贸绦驅Ψ掌魃汐@取的鎖幾乎有完全的控制（并對鎖負責）。雖然 SQL Server 鎖管理器自動使用鎖保護事務，但這受客戶端應用程序發出的查詢類型和對結果的處理方式的直接鼓動。因此，大多數阻塞問題的解決方案都涉及檢查客戶端應用程序。

阻塞問題常要求檢查應用程序提交的 SQL 語句本身，以及檢查與連接管理、所有結果行的處理等有關的應用程序行為本身。如果開發工具不允許顯式控制連接管理、查詢超時、結果處理等，阻塞問題可能得不到解決。

設計應用程序以避免阻塞的準則包括：

◆不要使用或設計使用戶得以填寫編輯框的應用程序，編輯框會生成長時間運行的查詢。例如，不要使用或設計提示用戶輸入的應用程序，允許某些字段保留空白或允許輸入通配符。這可能導致應用程序提交運行時間過長的查詢，從而導致阻塞問題。

◆不要使用或設計使用戶得以在事務內輸入內容的應用程序。

◆允許取消查詢。

◆使用查詢或鎖定超時，防止失控查詢和避免分布式死鎖。

◆立即完成提取所有結果行。

◆使事務盡可能簡短。

◆顯式控制連接管理。

◆在所預計的并發用戶全負荷下對應用程序進行應力測試。