我們在表上實現了6-7觸發器，並且有4個更新觸發器不在這些觸發器中。由於數據操作和條件，所有4個觸發器都需要長時間處理。但是，無論何時執行觸發器，網站上的所有頁面都會停止響應並掛起來自不同系統的其他用戶。即使我們在觸發器持有表上執行SQL Server Management Studio中的update語句，它也會掛起。我們可以通過將此觸發器代碼移入存儲過程並在表的update語句之後調用此存儲過程來解決此懸掛問題嗎？SQL Server數據庫在觸發器執行時掛起
因爲我認爲觸發器在執行時阻止表訪問其他用戶。如果沒有，那麼任何人都可以提供解決方案。
觸發器非常危險 - 只要事情發生，觸發器就會被觸發，而且無法控制觸發的時間和頻率。
你絕對應該是不是在觸發器中做任何耗時的處理！一個觸發器應該超級快，精益。
如果需要處理 - 讓觸發器將需要的信息記錄到單獨的「命令」表中，並讓另一個進程（例如預定的SQL代理作業）檢查該表以執行命令，然後執行這些命令 - 獨立於主應用程序，分開執行路徑。
不要通過在觸發器中進行過多的數據處理/操作來阻止您的主應用程序！這是做錯的地方！
我們可以通過將此觸發器代碼移入存儲過程 並在表的update語句之後調用此存儲過程來解決此懸掛問題嗎？
你有一個重量噸的盒子。當你把它放進一個漂亮的包裝裏時，它會變得更輕鬆嗎？
已經編譯了一個觸發器。把它放入存儲過程只是對它進行不同的修飾。
你的問題是，你濫用觸發器做重處理 - 他們不應該做的設計。改變設計。
因爲我認爲觸發器在執行時阻止表訪問其他用戶。
那麼，觸發器沒有這樣的事情 - 所以你認爲是錯的。
一個觸發器做它被告知要做的事情，一個空的觸發器設置零鎖（從任何觸發它的鎖都在那裏）。如果你確實設置了一個桌子寬大的鎖，不管誰這樣做並重新設計。
觸發器應該快速，輕便並且過快。在他們沒有重處理。
沒有實際看到的觸發是不可能的自信地診斷此但在這裏不用...
觸發器將不設鎖本身，而是它是否襯托其他UPDATE語句，他們將需要鎖和如果那些UPDATE語句觸發了其他觸發器，那麼你可能會產生一種連鎖反應，它會產生你似乎正在經歷的那種悲傷。
如果這聽起來像是可能發生的情況，那麼刪除觸發器並通過在末尾運行存儲過程來顯式執行處理可能會解決此問題。如果存儲過程是垃圾，那麼你仍然有問題，但至少他們會更容易修復。嘗試確保存儲過程只更新需要更新的記錄
將功能轉移到更新後運行的存儲過程的主要問題是確保每次都運行該存儲過程。
如果你的asp.net技能比你的T-SQL技能更強，那麼與解開一個SQL觸發器網絡相比，這應該是一個更容易解決的問題。
另一個問題是更新完成和完成記錄的存儲過程之間將處於顯示初始更改的中間狀態，而不是剩餘狀態。這可能是也可能不是你的情況下的問題