说说SQL Server触发器那些事儿，怎么用才不踩坑其实挺重要

说到SQL Server数据库，触发器这玩意儿就像是个藏在桌子底下的自动开关，你用得好，它能帮你省不少事儿，自动帮你干很多活；但你要是没弄明白就乱用，它分分钟能把你的系统搞得一团糟，排查问题的时候能让你头疼死，今天咱们就聊聊触发器那些事儿,重点是怎么用才能不踩坑。

触发器到底是个啥？简单打个比方

你别把它想得太复杂，你就把它想象成你家的智能门铃，当有人按门铃（这个动作就像是数据库里的INSERT、UPDATE或DELETE操作）时，这个智能门铃不单单是响一下，它还能自动执行一连串你预设好的动作：客厅的灯自动亮起（像是在日志表里记一笔），摄像头拍张照片（像是更新另一个相关表的数据），甚至给你手机发个通知（像是发送一封邮件）。

在SQL Server里，触发器就是一段特殊的存储过程，它不需要你手动去调用（EXECUTE），它“绑定”在某一张具体的表上，当这张表发生了特定的事件（增、删、改）时，SQL Server就会自动触发它执行，它就像是表的贴身保镖兼秘书，事件一发生,它立马行动。

触发器怎么用？两种主要的类型

最常见的有两种触发器,你得先分清楚：

1. AFTER 触发器（也叫 FOR 触发器）：这是最常用的，就像它的名字，它在主操作之后才执行，你执行了一条INSERT语句，新数据已经成功地插入到表里了，这个AFTER INSERT触发器才会被激活，它通常用于做后续处理，比如数据校验、更新汇总信息、写操作日志等，因为它发生在事情之后，所以如果触发器内部执行失败了，之前那个主操作（INSERT）也会被撤销掉,这叫事务回滚。

   

2. INSTEAD OF 触发器：这个就更“霸道”一点，它的意思是“取而代之”，当触发事件发生时，它根本不让那个原始的操作执行，而是直接由触发器里的代码来代替执行，这个特别有用在复杂的视图上，比如你有一个视图是由好几个表连接起来的，你想直接对这个视图进行插入操作，数据库本来是不知所措的，但你可以创建一个INSTEAD OF INSERT触发器,在触发器里写明到底应该往哪几个基表里怎么插入数据。

重中之重：怎么用才不踩坑？

这才是关键，很多人觉得触发器好用就滥用,结果埋下了大坑。

第一大坑：性能杀手。 触发器是自动执行的，藏在暗处，你写的一条看似简单的UPDATE语句，可能因为触发了触发器，而实际上在背后执行了非常复杂的逻辑和大量的SQL操作，如果这张表操作频繁，触发器又写得很臃肿，整个数据库的性能都会被它拖慢，而且性能问题很难排查，你可能花了半天时间优化你的主SQL，却没想到问题出在背后这个“隐形人”身上。

• 避坑指南：触发器里的逻辑一定要简单高效！能不用就不用，如果业务逻辑非常复杂，考虑把它放到应用程序层或者显式调用的存储过程里,这样至少大家都知道这里有一大段代码要跑。

第二大坑：递归和嵌套的陷阱。 这是个非常危险的情况，你在表A上写了一个触发器，这个触发器执行时又去更新了表A自己，这就会导致触发器再次被触发，从而形成无限循环，直到把数据库拖垮，SQL Server虽然有设置可以禁止递归触发器，但默认是开启的,一不小心就会中招。

• 避坑指南：在设计触发器时，脑子里一定要有根弦：绝对避免在触发器内部去操作触发器所在的表本身，除非你有万分把握并且做了严格的递归终止条件,检查数据库的递归触发器选项是否必要。

第三大坑：数据逻辑变得隐晦和难以维护。 业务逻辑散落在应用程序代码和数据库的各个触发器里，时间一长，后来接手的程序员根本不知道改一张表还会引发这么多连锁反应，调试起来也极其困难,因为你无法直接从应用程序的调用栈里看到触发器的存在。

• 避坑指南：给触发器起一个清晰明了的名字，比如trg_AuditOrderChanges（审计订单变更的触发器），并在触发器内部写上详细的注释，说明它的目的、触发条件、做了什么事情，如果业务逻辑复杂且重要,尽量优先考虑在应用层实现。

第四大坑：处理多行数据时出错。 这是初学者最容易犯的错误，触发器是针对语句触发的，而不是行，也就是说，你一条UPDATE语句可能更新了100条记录，触发器只触发一次，而不是100次，在触发器内部，你需要通过访问特殊的临时表inserted和deleted（分别存放新增的数据和删除/更新前的旧数据）来处理这所有100行数据，如果你错误地认为触发器会逐行处理，写了只处理单行的代码,那就会出大问题。

• 避坑指南：在触发器里，务必假设inserted和deleted表里会有多行数据，你的代码必须能用集合操作（比如基于集合的UPDATE、DELETE或使用游标）来处理所有行,而不能用只返回单标量的变量赋值方式。

第五大坑：事务的“绑架”。 触发器运行在它所属语句的事务内部，这意味着，如果触发器执行时间很长，它会锁住相关资源，导致其他会话被阻塞，更关键的是，如果触发器执行失败（比如违反了某个约束），它会导致整个原始操作的事务回滚,这可能不是你想要的。

• 避坑指南：意识到触发器是事务的一部分，如果触发器里的某些操作是可选的，或者失败了也不希望影响主业务，可以考虑在触发器内部使用BEGIN TRY...END TRY块来捕获异常，并对非核心逻辑的错误进行容错处理，但这样做要非常小心,因为这可能掩盖真正的问题。

SQL Server触发器是一个强大的工具，但它是一把双刃剑，它的“自动化”和“隐蔽性”既是优点也是最大的缺点，在使用它之前，一定要反复问自己：这个逻辑是否必须用触发器实现？有没有更简单、更明显的方式？如果非用不可，一定要遵循“简单、高效、清晰、防递归、处理多行”的原则，这样才能让它真正为你服务，而不是给你挖坑，根据微软MSDN文档关于触发器设计的建议，一个核心原则就是保持触发器的简洁和高效,避免在其中进行复杂的业务处理。