我们在表上实现了6-7触发器，并且有4个更新触发器不在这些触发器中。由于数据操作和条件，所有4个触发器都需要长时间处理。但是，无论何时执行触发器，网站上的所有页面都会停止响应并挂起来自不同系统的其他用户。即使我们在触发器持有表上执行SQL Server Management Studio中的update语句，它也会挂起。我们可以通过将此触发器代码移入存储过程并在表的update语句之后调用此存储过程来解决此悬挂问题吗？SQL Server数据库在触发器执行时挂起
因为我认为触发器在执行时阻止表访问其他用户。如果没有，那么任何人都可以提供解决方案。
触发器非常危险 - 只要事情发生，触发器就会被触发，而且无法控制触发的时间和频率。
你绝对应该是不是在触发器中做任何耗时的处理！一个触发器应该超级快，精益。
如果需要处理 - 让触发器将需要的信息记录到单独的“命令”表中，并让另一个进程（例如预定的SQL代理作业）检查该表以执行命令，然后执行这些命令 - 独立于主应用程序，分开执行路径。
不要通过在触发器中进行过多的数据处理/操作来阻止您的主应用程序！这是做错的地方！
我们可以通过将此触发器代码移入存储过程 并在表的update语句之后调用此存储过程来解决此悬挂问题吗？
你有一个重量吨的盒子。当你把它放进一个漂亮的包装里时，它会变得更轻松吗？
已经编译了一个触发器。把它放入存储过程只是对它进行不同的修饰。
你的问题是，你滥用触发器做重处理 - 他们不应该做的设计。改变设计。
因为我认为触发器在执行时阻止表访问其他用户。
那么，触发器没有这样的事情 - 所以你认为是错的。
一个触发器做它被告知要做的事情，一个空的触发器设置零锁（从任何触发它的锁都在那里）。如果你确实设置了一个桌子宽大的锁，不管谁这样做并重新设计。
触发器应该快速，轻便并且过快。在他们没有重处理。
没有实际看到的触发是不可能的自信地诊断此但在这里不用...
触发器将不设锁本身，而是它是否衬托其他UPDATE语句，他们将需要锁和如果那些UPDATE语句触发了其他触发器，那么你可能会产生一种连锁反应，它会产生你似乎正在经历的那种悲伤。
如果这听起来像是可能发生的情况，那么删除触发器并通过在末尾运行存储过程来显式执行处理可能会解决此问题。如果存储过程是垃圾，那么你仍然有问题，但至少他们会更容易修复。尝试确保存储过程只更新需要更新的记录
将功能转移到更新后运行的存储过程的主要问题是确保每次都运行该存储过程。
如果你的asp.net技能比你的T-SQL技能更强，那么与解开一个SQL触发器网络相比，这应该是一个更容易解决的问题。
另一个问题是更新完成和完成记录的存储过程之间将处于显示初始更改的中间状态，而不是剩余状态。这可能是也可能不是你的情况下的问题