阻塞的常見原因和解決辦法：
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 重啟的時候會重新開始。重啟的時候如果回滾不能很快結束，整個資料庫都會不可用。
解決辦法：
最好的方法是在工作時間盡量不要做這種大的修改操作。這些操作要盡量安排在半夜或週末的時間完成。如果操作已經進行了很久，最好耐心等它做完。如果一定要在有工作負荷的時候做，最好把乙個大操作分成若干小操作分布完成
5.
應用程式中產生死鎖
Sql Server 阻塞的常見原因和解決辦法
阻塞的常見原因和解決辦法 1.由於語句執行時間太長而導致的阻塞，語句本身在正常執行中，只須等待某些系統資源 解決辦法 a.語句本身有沒有可優化的空間 b.sql server 整體效能如何，是不是有資源瓶頸影響了語句執行速度，如 記憶體 硬碟 和 cpu 等 2.由於乙個未按預期提交的事務導致的阻塞...
sqlserver死鎖阻塞
create proc p lockinfo kill lock spid bit 1,是否殺掉死鎖的程序,1 殺掉,0 僅顯示 show spid if nolock bit 1 如果沒有死鎖的程序,是否顯示正常程序資訊,1 顯示,0 不顯示 as declare count int,s nvar...
sql server 阻塞查詢
原文 sql server 阻塞查詢 在生產環境下，有時公司客服反映網頁半天打不到，除了在瀏覽器按f12的network響應來排查，確定web伺服器無故障後。就需要檢查資料庫是否有出現阻塞 當時資料庫的生產環境中主表資料量超過2000w,子表資料量超過1億，且更新和新增頻繁。再加上做了同步映象，很消...