会回滚，且整个事务从begin或隐式起点开始全部回滚；触发器无独立事务上下文，其错误（如signal、外键冲突）导致原语句失败并连带已执行操作一并撤销。
触发器执行失败时，事务是否回滚，不取决于触发器本身，而取决于你有没有显式中断当前事务上下文。 MySQL 和 SQL Server 行为差异极大，硬套一种逻辑会直接导致数据不一致。
SQL Server 触发器里 RAISERROR 不会自动回滚事务
很多人写完 RAISERROR('校验失败', 16, 1) 就以为事务结束了，结果发现 INSERT 已经落库。这是因为 RAISERROR 只是抛错，不终止事务流。
- 必须紧跟着
ROLLBACK TRANSACTION，且要放在IF条件分支末尾或TRY...CATCH的CATCH块里 - 推荐改用
THROW（SQL Server 2012+），它默认中断批处理，再配合SET XACT_ABORT ON才能可靠中止整个事务 - 不要在
TRY块里只RAISERROR而不ROLLBACK——CATCH里没回滚，事务仍挂起，可能阻塞后续操作 - 嵌套触发器中
@@TRANCOUNT会累加，但一次ROLLBACK就能回到最外层起点，不用循环回滚
MySQL BEFORE 触发器失败 = 主语句失败，但不能依赖它做复杂逻辑
MySQL 的 BEFORE 触发器里执行 SIGNAL SQLSTATE '45000'，会直接让 INSERT/UPDATE 失败并回滚——这是由引擎保证的原子性。但它不是万能兜底。
-
SIGNAL适合简单校验（如IF NEW.amount ），不适合需要日志、重试或降级的场景 - 一旦触发器里发生未捕获异常（比如除零、表不存在），整个语句失败，但错误信息模糊，难定位
- 想记录错误又不让主事务失败？得用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获并写日志表，而不是靠SIGNAL - 复杂业务逻辑（如调用外部服务、更新多张关联表）应移出触发器，放到应用层或存储过程里统一控制事务边界
autocommit=true 是事务失效的隐形杀手
无论 MySQL 还是 SQL Server，只要连接处于自动提交模式，BEGIN TRANSACTION 和 ROLLBACK 都是摆设。
- SQL Server 驱动（如
go-mssqldb）默认autocommit=true，必须在连接字符串里显式加autocommit=false - MySQL 默认
autocommit=1，单条 UPDATE/DELETE 执行完立刻提交，根本没法回滚 - DDL 语句（
CREATE TABLE、ALTER TABLE）、LOCK TABLES、甚至某些SELECT ... FOR UPDATE都会隐式提交当前事务，让前面的START TRANSACTION失效 - 用
SHOW ENGINE INNODB STATUS查TRANSACTIONS段，能确认事务是否真正在运行，而不是被悄悄提交了
真正容易被忽略的点在于：触发器只是事务里的一个环节，它没有独立事务生命周期。它的成败，最终要靠上层连接状态、错误处理方式和引擎行为共同决定。别把校验逻辑全塞进触发器，也别假设抛个错就万事大吉——检查 @@TRANCOUNT、关掉 autocommit、用 THROW 替代 RAISERROR，这些才是稳住数据一致性的实际动作。
