kry*_*lon 6 trigger performance sql-server
我被赋予了光荣的添加任务——非常小心！- 我们的 ERP 系统数据库的一些触发器，以“实时”从 ERP 系统获取数据到我们公司运行的其他软件。触发器不会对数据进行任何更改，只需从插入/更新行中选取一些字段，将它们汇总到 XML 消息中并将它们发送到消息队列。也不会有 JOIN。（这是否是一个好主意，这是另一个问题。）
我可以想象编写多个触发器，每个场景一个。或者我可以编写两个大型触发器，一个用于插入，一个用于更新。如果有足够的力量，我什至可以将其归结为一个在 INSERT 和 UPDATE 上运行的巨大触发器。
从测试/调试/维护的角度来看，几个独立的触发器具有明显的优势：每个触发器都可以单独编写、测试和启用/禁用。每个触发器都会检查相应表中刚刚发生的事情是否与该触发器相关，如果是，它将执行其操作，如果不是，它将退出。
但是，我担心多个触发器可能会导致性能问题。我应该附加这些触发器的表将频繁的 INSERT 和 UPDATE 查询视为正常操作的一部分[1]。（OTOH，到目前为止，数据库服务器上的负载相对较轻。）
是否有关于哪种方法更好的一般准则？
非常感谢您能够分享的任何信息，本杰明
[1] 在这种情况下，频繁意味着“繁忙的一天每分钟有几十笔交易”。
小智 5
听起来你已经知道正确答案了。最好的方法是以最少的代码量使触发代码运行得最快。如果是我，我每个动作都会有一个触发器。是否会有重复的代码 - 绝对的 - 但它可以帮助您在需要更改任何内容时节省时间，并且可以根据情况进行自定义。
您可以尝试两者，然后模拟负载以查看您最喜欢/表现最好的。Aaron Bertrand 发现多个触发器执行相同操作会产生明显的额外开销，但是 YMMV。
然而，每分钟几十笔交易听起来并不是一个巨大的活动量。可维护性“可能”能够证明少量的开销是合理的。使用单独的“单功能”触发器有很多优点。正如您所指出的，它们只有一个目的，可以单独测试（由不同的人）、启用、禁用。将处理隔离为单独的“单功能”触发器“可能”降低未来维护所涉及的风险。
当然，各个触发器的最终测试不能由不同的人进行，因为您需要确保触发器一致地正常工作。而且，虽然将来维护较小的代码块在逻辑上更容易，但在进行将来的更改时不能忽略其他触发器，因为在触发器 A 中不会导致问题的某些操作可能会完全搞乱触发器 C 正在执行的操作。