触发器性能：使用触发器是一种好方法吗？

Question

我们正在使用SQL Server 2008j2ee Web 应用程序。我需要维护每个列的更新审计，其中有一个表非常重，大约有 100 列和 10K 条记录，并且每天都在快速增加。大约 200 名用户使用此应用程序，更新也非常频繁。我知道通过代码处理它需要非常频繁地连接到数据库。我想知道哪种方法更好。通过代码处理它会提供比使用它更好的性能SQL Server trigger。

Answer 1

就个人而言，我会使用触发器进行审计。

• 如果失败，则主 DML 将回滚
• （同）主更新需要DML成功
• 一个表通常会有几个 DML 路径
• 您可能无法使用代码
• 您将在某个时候直接更新表格以绕过代码

好的，所以我们将使用触发器。一些笔记

• 确保它们适用于多行：没有 CURSOR 或循环
• 仅将它们用于审计：没有别的（不，比如说，发送电子邮件）
• 确保在触发器中使用 TRY/CATCH：这极大地改善了触发器中回滚的行为
• CASCADE 外键会导致子表触发器触发：注意嵌套和递归，如果可能，不要使用 CASCADE

最后一个列表还解决了@NevilleK 回答中的问题。触发器是一种可以使用的工具：明智地使用，并在适当和正确的情况下使用。

每小时 600 次更新是微不足道的，对于触发器来说根本不是问题（受游标、循环、发送电子邮件和其他愚蠢的东西的影响）

Answer 2

有一个应用程序可以为您创建触发器 - ApexSQL Audit。然后你可以测试行为，但根据你所说的，它不是一个高事务数据库，所以应该没有问题。可用于审核数据更改的另一种资源是读取事务日志。

Answer 3

出于与 gbn 所述相同的原因，我可能会坚持使用触发器，但如果性能成为问题，您可能需要考虑使用 Service Broker 异步执行工作（如果业务需求允许）。典型的设计是让触发器调用一个发送 Service Broker 消息的存储过程，Service Broker 队列处理发生延迟的工作。

这是我写的一篇简短（非商业性）文章，可能有助于防止任何触发器失控： 编写行为良好的触发器