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