mysql 触发器 事物优先级
背景：
tableA上有触发器triggerA（insert）,triggerA会向备份库的tableA插入相同数据 。
现在在同一事物下向tableA和tableB里插入数据 ，向tableB插入时发生异常
对比：
| 表 | 预期 | 实际 |
|---|---|---|
| tableA | 回滚 | 回滚 |
| tableB | 不插入 | 不插入 |
| 备份库tableA | 不插入 | 插入 |
疑问：
触发器的触发不是在事物commit之后吗？
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
触发器的执行实际上是在数据库事务处理过程中，当满足触发条件（如INSERT、UPDATE或DELETE等操作）时立即发生的，而不是在事务提交（commit）之后。这意味着，只要触发事件发生，触发器就会按照定义的逻辑即时执行，无论事务最终是否成功提交。
在您描述的场景中，向tableA插入数据时，由于triggerA是针对INSERT操作定义的，所以在同一事务内向tableA插入数据的瞬间，triggerA就会被激活，并尝试向备份库的tableA插入相同的数据。这个过程发生在事务提交之前。
如果随后的操作——向tableB插入数据时发生了异常，并且这个异常导致了整个事务的回滚，那么tableA中的插入操作以及由triggerA引起的备份库中tableA的插入都将被撤销，因为它们都是同一个事务的一部分。但是，这里有一个关键点需要注意：如果触发器内的操作（即向备份库插入数据）使用了不同的事务管理方式，或者明确地独立提交了事务，那么它可能不会随着原事务的回滚而回滚。
通常情况下，触发器内部的操作被视为原事务的一部分，因此会遵循相同的事务边界，即如果主事务回滚，触发器所做的一切也会被回滚。但这也依赖于具体的数据库管理系统(DBMS)实现和触发器内部的编程逻辑。确保触发器的行为符合预期，需要检查和设计时考虑这些细节。
总结来说，根据您的描述，如果一切操作都在一个事务中进行，且没有特殊处理来改变事务行为，那么当事务因向tableB插入数据时的异常而回滚时，tableA及其备份库中的对应记录都应该被正确地回滚，不会出现备份库中有插入而主库没有的情况。
