是的，mysql触发器抛错（如signal、字段名拼错、约束冲突）会导致整个事务回滚，这是innodb强制保障的原子性行为，而非bug；触发器与主dml共享同一事务上下文，错误即标记事务失败，所有变更一并回滚。
MySQL 触发器抛出错误（如 SIGNAL、字段名拼错、约束冲突）后整个事务回滚，不是 bug，而是 InnoDB 强制保障的原子性行为——它本就该这样。你没法“阻止”它回滚，但可以控制“什么情况下抛错”“错得是否干净”“有没有留下副作用”。关键不在绕过回滚，而在让回滚发生得可预期、可追溯、不污染状态。
MySQL BEFORE 触发器里 SIGNAL 为什么会连主语句一起撤掉
因为触发器和主 DML（比如 INSERT INTO orders）共享同一个事务上下文，不是两个独立事务。SIGNAL 不是“我报个错”，而是“这个语句现在无效”，引擎立刻标记事务失败，后续不再执行任何逻辑，已做的变更（包括主语句写入、触发器内 SET NEW.x = ...）全部进 undo log 回滚队列。
- 仅在
ENGINE=InnoDB表上生效；MyISAM 表无视SIGNAL，也不支持事务 -
autocommit = 1时，单条语句本身就是事务，回滚只影响它自己，但你感知不到——查表就是空的 -
AFTER触发器里用SIGNAL没用：数据已经落库，再抛错只能回滚触发器内操作，主语句不会撤 - 别在
SIGNAL前做不可回滚操作，比如调用外部 HTTP 接口、写普通日志表——这些不会随事务撤销
SQL Server 触发器里 RAISERROR 为什么没回滚，而 THROW 配合 SET XACT_ABORT ON 才行
RAISERROR 只是抛异常消息，不改变事务状态；THROW 默认中断当前批处理，但若没开 XACT_ABORT，仍可能只终止当前语句，外层事务继续运行。
- 必须写
SET XACT_ABORT ON在触发器开头（不是连接字符串里），否则THROW后COMMIT仍可能成功 -
RAISERROR('msg', 16, 1)后必须紧跟IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION，且不能包在未执行的IF分支里 - 嵌套触发器中
@@TRANCOUNT会累加，但一次ROLLBACK就回到最外层起点，不用手动判断层数 - 别在
TRY...CATCH的CATCH块里只RAISERROR而不ROLLBACK——事务挂起，后续操作可能卡死或报ERROR 3903
触发器报错后查不到错误信息，怎么快速定位
错误常被吞掉，客户端看到的是“成功”或模糊的 ERROR 1422，实际原因藏在别处。
- MySQL：执行完疑似失败的 DML 后**立刻**跑
SHOW WARNINGS，90% 的真实报错在这里，比如Warning 1327 Undeclared variable: NEW.invalid_col - SQL Server：触发器开头加
RAISERROR('trg fired', 0, 1) WITH NOWAIT，用 SSMS “消息”窗口确认是否真执行了 - 检查日志配置：
SELECT @@log_error看路径，MySQL 8.0+ 要设log_error_verbosity = 3才记录触发器内警告 - 验证表引擎和模式：
SHOW CREATE TABLE t确认含ENGINE=InnoDB；SELECT @@sql_mode确保含STRICT_TRANS_TABLES，否则类型不匹配会被静默截断
想记录错误又不想破坏事务，还能怎么做
直接往普通表里 INSERT INTO error_log 不行——它参与事务，一回滚就没了。得用不参与事务的存储引擎或异步机制。
- MySQL：把日志表引擎设为
BLACKHOLE或ARCHIVE，它们不写数据页，也不进事务日志，INSERT永远成功且不可回滚 - SQL Server：用
sp_audit_write（SQL Server 2016+）或写到sys.fn_dblog()外部表，避开事务上下文 - 更稳妥的做法是移出触发器：把校验/日志/通知逻辑提到应用层或存储过程中，在统一事务边界里控制成败
- 如果非要在触发器里发通知，改用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获错误并写日志，而不是靠SIGNAL中断——后者是“拒绝”，前者是“记下然后放行”
真正容易被忽略的点是：触发器没有自己的事务生命周期，它只是主事务的一个执行阶段。你看到的“回滚”，其实是数据库在说：“这一整段操作，从开始到现在，都不算数。” 所以排查重点从来不是“怎么不让它回滚”，而是“它为什么在这个点失败”“失败前有没有留下不可逆痕迹”“下游系统是否感知到了这次失败”。
