2018.12.29
今天着实被触发器坑了一把。
运维的系统当中有一个功能需要调用某个存储过程,这个存储过程总是运行到一半就失败了。而在服务器的SSMS执行exec XXX,却可以正常执行,百思不得其解。
后来,对于存储过程进行了调试,逐句分析(F11),发现存储过程中操作的几个表都带有触发器,其中一个触发器的语句中有一个耗时较长,所以导致了客户端远程调用时出现了超时的情况。于是对触发器进行了改进,解决了问题。
但是这次问题的解决也让我对触发器有了新的认识。以前,我只是觉得触发器是方便我们工作的一个自动化工具,毕竟是“一次添加,终生受用”,而且还能对表进行了一定程度的约束。但通过今天的问题,结合翻阅的资料,我发现触发器也有以下缺点:
1可移植性差;
2.占用服务器资源,给服务器造成压力;
3.执行速度主要取决于数据库服务器的性能与触发器代码的复杂程度;
4.嵌套调用一旦出现问题,排错困难,而且数据容易造成不一致,后期维护不方便。
触发器其实更像是一种添加了触发条件的存储过程,而说到存储过程就不得不提事务。触发器有一个比较有意思的地方是,如果触发器发生了回滚,那么他会和调用他的句子一起回滚。
综合以上,我们应该从这次问题学习到什么呢?那就是触发器的设计问题:触发器应该在什么情况下使用,用的时候应该避免怎样的问题?待更新。