触发器及事务

　　写在文章之前，希望使用触发器的同仁慎之又慎；触发器提供的便利自不用说，但是它的弊端会在日后慢慢显现，是难以及时察觉的。在两年的使用中，多次因触发器引发应用系统故障。这种故障很难察觉，通过sqlsever的跟踪器也无法抓到错误代码。有时候你抓到一段简单的插入语句，cpu耗时少，读取和写入的数据量很小，也没发现任何阻塞但是这个插入就是耗时很长；有时候是很简单的业务逻辑的实现，软件代码很简单看不出来任何，可是功能就是达不到预期；还有时候就是需求变更了，修改软件模块，怎么也找不到某一块业务逻辑的数据实现；对，都是触发器这个始作俑者在搞鬼；

　　读者能在软件中实现的尽量不要用触发器。实在要使用触发器，尽量缩小触发器的作用范围，比如用update(),仅是更新某一字段时触发；

1.触发器与事务的关系

　触发器可以被认为是一个隐式的嵌套事务。嵌套在引发它的事务中。

 2.触发器与约束的关系。见下图。

   after 触发器先验证约束，然后激活触发器。

   instead  of 触发器刚好相反。

 

 

 

 

 

 

 

 

 

 

 

3.触发器中的回滚操作

　a、显示的回滚，将撤销从最外层的begin tran开始的所有操作。

    b、隐式的回滚，将撤销触发器内rollback以前的所有操作，并撤销触发语句。

    c.可以通过save tran创建保存点，回退部分操作。或者在触发器中提前commit事务。

 

　　由于隐式的包含事务，在触发器中出现rollback或者commit后，需要在写一个begin tran.具体见图：

  

    d.特别注意：触发器中的回滚操作之后的语句将被继续执行，然后触发语句所在的批处理之后的语句将被终止执行。

4.触发器嵌套及递归

   a.服务器默认开启触发器嵌套。且最高嵌套32层。超过限制后回滚所有的操作。

　　相关选项：nested triggers

   b.服务器默认不开启触发器递归。

　　相关选项：recursive_triggers