sql server 本質上是受客戶端應用程式操縱的傀儡。客戶端應用程式對伺服器上獲取的鎖幾乎有完全的控制(並對鎖負責)。雖然 sql server 鎖管理器自動使用鎖保護事務，但這受客戶端應用程式發出的查詢型別和對結果的處理方式的直接鼓動。因此，大多數阻塞問題的解決方案都涉及檢查客戶端應用程式。
當來自應用程式的第乙個連線控制鎖而第二個連線需要相衝突的鎖型別時，將發生阻塞。其結果是強制第二個連線等待，而在第乙個連線上阻塞。不管是來自同一應用程式還是另外一台客戶機上單獨的應用程式，乙個連線都可以阻塞另乙個連線。
說明一些需要鎖保護的操作可能不明顯，例如系統目錄表和索引上的鎖。
大多數阻塞問題的發生是因為乙個程序控制鎖的時間過長，導致阻塞的程序鏈都在其它程序上等待鎖。
常見的阻塞情形包括：
提交執行時間長的查詢。
長時間執行的查詢會阻塞其它查詢。例如，影響很多行的 delete 或 update 操作能獲取很多鎖，這些鎖不論是否公升級到表鎖都阻塞其它查詢。因此，一般不要將長時間執行的決策支援查詢和聯機事務處理 (oltp) 查詢混在一起。解決方案是想辦法優化查詢，如更改索引、將大的複雜查詢分成簡單的查詢或在空閒時間或單獨的計算機上執行查詢。
查詢執行時間長並由此導致阻塞的乙個原因是這些查詢不適當地使用游標。游標可能是在結果集中瀏覽的便利方法，但使用游標可能比使用面向集合的查詢慢。
取消沒有提交或回滾的查詢。
如果應用程式取消查詢(如使用開放式資料庫連線 (odbc) sqlcancel 函式)但沒有同時發出所需數目的 rollback 和 commit 語句，則會發生這種情況。取消查詢並不自動回滾或提交事務。取消查詢後，所有在事務內獲取的鎖都將保留。應用程式必須提交或回滾已取消的事務，從而正確地管理事務巢狀級。
應用程式沒處理完所有結果。
將查詢傳送到伺服器後，所有應用程式必須立即完成提取所有結果行。如果應用程式沒有提取所有結果行，鎖可能會留在表上而阻塞其他使用者。如果使用的應用程式將 transact-sql 語句透明地提交給伺服器，則該應用程式必須提取所有結果行。如果應用程式沒這樣做(如果無法配置它執行此操作)，則可能無法解決阻塞問題。為避免此問題，可以將這些應用程式限制在報表或決策支援資料庫上。
分布式客戶端/伺服器死鎖。
與常規死鎖不同，分布式死鎖無法由 microsoft® sql server™ 2000 自動檢測到。如果應用程式開啟多個與 sql server 的連線並非同步提交查詢，則可能會發生分布式客戶端/伺服器死鎖。
例如，乙個客戶端應用程式執行緒有兩個開放式連線。該執行緒非同步啟動事務並在第乙個連線上發出查詢。應用程式隨後啟動其它事務，在另乙個連線上發出查詢並等待結果。當 sql server 返回其中乙個連線的結果時，應用程式開始處理這些結果。應用程式就這樣處理結果，直到生成結果的查詢被另乙個連線上執行的查詢阻塞而導致再沒有可用的結果為止。此時第乙個連線阻塞，無限期等待處理更多的結果。第二個連線沒有在鎖上阻塞，但仍試圖將結果返回給應用程式。然而，由於應用程式阻塞而在第乙個連線上等待結果，第二個連線的結果將得不到處理。
若要避免此問題，請執行下列任一操作：
對每個查詢使用查詢超時。
對每個查詢使用鎖定超時。
使用繫結連線。
sql server 本質上是受客戶端應用程式操縱的傀儡。客戶端應用程式對伺服器上獲取的鎖幾乎有完全的控制(並對鎖負責)。雖然 sql server 鎖管理器自動使用鎖保護事務，但這受客戶端應用程式發出的查詢型別和對結果的處理方式的直接鼓動。因此，大多數阻塞問題的解決方案都涉及檢查客戶端應用程式。
阻塞問題常要求檢查應用程式提交的 sql 語句本身，以及檢查與連線管理、所有結果行的處理等有關的應用程式行為本身。如果開發工具不允許顯式控制連線管理、查詢超時、結果處理等，阻塞問題可能得不到解決。
設計應用程式以避免阻塞的準則包括：
不要使用或設計使使用者得以填寫編輯框的應用程式，編輯框會生成長時間執行的查詢。例如，不要使用或設計提示使用者輸入的應用程式，允許某些字段保留空白或允許輸入萬用字元。這可能導致應用程式提交執行時間過長的查詢，從而導致阻塞問題。
不要使用或設計使使用者得以在事務內輸入內容的應用程式。
允許取消查詢。
使用查詢或鎖定超時，防止失控查詢和避免分布式死鎖。
立即完成提取所有結果行。
使事務盡可能簡短。
顯式控制連線管理。
在所預計的併發使用者全負荷下對應用程式進行應力測試。
設計Web應用程式時要注意可伸縮性
max indelicato是一位軟體開發主管和前首席軟體架構師，他最近發表了一篇關於如何設計具備可伸縮性的web應用程式 的文章。他提出要選擇正確的部署和儲存解決方案，選擇可伸縮的資料儲存和模式，並且使用抽象層。indelicato的第乙個建議是 為工作選擇正確的工具 想要達到這個目的，就要選擇下...
設計Web應用程式時要注意可伸縮性
適合工作的工具 indelicato的第乙個建議是 為工作選擇正確的工具 想要達到這個目的，就要選擇下列架構解決方案中的一種 他認為在開始開發應用程式的時候，這些解決方案並不是必須的，但是在開始時就選擇可伸縮的資料儲存解決方案是很明智的，因為那會避免之後再進行切 換。將應用程式部署到雲中會為我們帶來...
設計Web應用程式時要注意可伸縮性
max indelicato是一位軟體開發主管和前首席軟體架構師，他最近發表了一篇關於如何設計具備可伸縮性的web應用程式 的文章。他提出要選擇正確的部署和儲存解決方案，選擇可伸縮的資料儲存和模式，並且使用抽象層。indelicato的第乙個建議是 為工作選擇正確的工具 想要達到這個目的，就要選擇下...