SQL Server数据库在触发器执行时挂起

Question

我们在一个表上实现了6-7个触发器，其中有4个update触发器。由于数据操作和条件的原因，这4个触发器都需要长时间的处理。但是，每当触发器执行时，网站上的所有页面都会停止响应，并且对于来自不同系统的其他用户也会挂起。即使我们在SQL Server Management Studio中对触发器存储表执行update语句，它也会挂起。我们可以通过将此触发器代码转移到存储过程中并在表的update语句之后调用此存储过程来解决此挂起问题吗？

因为我认为触发器在执行时阻止了其他用户对表的访问。如果没有，那么任何人都可以提供解决方案。

Answer 1

触发器是危险的-无论什么时候发生事情，它们都会被触发，而您无法控制它们何时触发以及触发的频率。

你绝对应该在触发器中而不是做任何耗时的处理！触发器应该非常快，而且要倾斜。

如果您需要处理-让触发器将所需的信息记录到单独的“命令”表中，并让另一个进程(例如，计划的SQL代理作业)检查该表中要执行的命令，然后在单独的执行路径中独立于主应用程序执行这些命令。

不要通过在触发器中进行过多的数据处理/操作来阻止你的主应用程序！这不是做这件事的地方！

Answer 2

我们可以通过将此触发器代码转移到存储过程中并在表的update语句之后调用此存储过程来解决此挂起问题吗？

你有一个重达一吨的盒子。当你把它放进漂亮的包装里时，它会变得更轻吗？

触发器已编译。把它放到一个存储过程中只是用不同的方式来修饰它。

你的问题是，你滥用触发器来做繁重的处理--这是他们不应该设计的。更改设计。

，因为我认为触发器在执行时阻止了其他用户对表的访问。

嗯，触发器不做这样的事情-所以你想错了。

触发器做它被告知要做的事情，一个空的触发器设置零个锁(无论触发它的是什么，锁都在那里)。如果你设置了一个桌子宽的锁，不管是谁做的，都可以重新设计。

触发器应该是快速的，轻巧的，并且结束得很快。它们中没有繁重的处理。

Answer 3

在没有真正看到触发因素的情况下，不可能自信地诊断出这一点，但这就是……

触发器本身不会设置锁，但如果它触发了其他UPDATE语句，它们将需要锁，如果这些UPDATE语句触发其他触发器，那么您可能会产生连锁反应，从而产生您似乎正在经历的那种痛苦。

如果这听起来像是正在发生的事情，那么删除触发器并通过在结束时运行存储过程显式地执行处理可以修复它。如果存储过程是垃圾，那么您仍然会有问题，但至少它们会更容易修复。请尝试确保存储过程仅更新需要更新的记录

将功能转移到更新后运行的存储过程的主要问题是确保每次都实际运行它。

如果您的asp.net技能比T-SQL技能强，那么这应该比解开SQL触发器的网络容易得多。

另一个问题是，在更新完成和存储过程完成记录之间，将处于显示初始更改而不是其余更改的中间状态。对于您来说，这可能是问题，也可能不是问题。