最典型的“隐式回滚”现象是触发器报错却不提示、数据未写入：MySQL吞错需SHOW WARNINGS查看，SQL Server中RAISERROR不自动回滚需手动ROLLBACK，THROW需配合SET XACT_ABORT ON才可靠终止事务。
触发器报错却不提示，数据却没写进去
这是最典型的“隐式回滚”现象：你执行了 INSERT，语句返回成功或无报错，但查表发现数据没插入；或者反过来，明明触发器里写了 RAISERROR 或 THROW，客户端却只看到模糊的 ERROR 1452 或干脆静默失败。
根本原因在于：MySQL 和 SQL Server 对触发器内错误的传播策略不同，且默认不把内部错误透出到客户端。
- MySQL 触发器里发生 SQL 错误（比如字段不存在、类型不匹配、
SELECT返回结果集），整个 DML 会失败，但错误被吞掉——必须立刻执行SHOW WARNINGS才能看到真实报错，例如Unknown column 'xxx' in 'field list' - SQL Server 中
RAISERROR默认不中断事务流，若没紧跟ROLLBACK TRANSACTION，上层INSERT可能照常提交，造成数据状态与业务逻辑严重错位 - 两者都受
sql_mode（MySQL）或SET XACT_ABORT（SQL Server）影响：MySQL 开启STRICT_TRANS_TABLES会让“无效更新”（如UPDATE t SET a=a）直接跳过触发器；SQL Server 关闭XACT_ABORT时，THROW可能只终止当前批，不回滚外层事务
如何确认触发器真的被执行了
别凭感觉判断触发器是否生效。很多问题其实源于触发器压根没跑起来，而不是它跑错了。
- MySQL：检查
BEFORE/AFTER是否匹配操作类型——BEFORE UPDATE不会在UPDATE t SET x=x（未实际变更）时触发；用SELECT @@sql_mode确认是否含STRICT_TRANS_TABLES - SQL Server：在触发器开头加一句
RAISERROR('trg fired', 0, 1) WITH NOWAIT，配合 SSMS 的“消息”窗口观察输出；注意不能用PRINT，它可能被缓冲延迟 - 通用验证法：在触发器里写一条测试日志（如向临时表
INSERT INTO debug_log VALUES (GETDATE(), 'trg_start')），再执行 DML 后查该表——只要日志有记录，就证明触发器确实运行了
RAISERROR 和 THROW 在事务控制上的行为差异
SQL Server 里这两个命令看着像，但对事务的影响天差地别，混用极易翻车。
-
RAISERROR('msg', 16, 1)只是抛错，不会自动回滚事务，也不会终止后续语句执行——必须手动跟ROLLBACK TRANSACTION，且要确保它一定执行（比如放在IF判断后，不要塞进TRY...CATCH里却不处理） -
THROW 50000, 'msg', 1默认中断当前批处理，但仍不保证回滚；必须搭配SET XACT_ABORT ON才能可靠中止整个事务（否则遇到死锁或某些错误时仍可能部分提交） - 严重级别陷阱：
RAISERROR级别的错误不会被客户端捕获，只会写日志（需WITH LOG）；级别10的错误甚至不会中断执行流
为什么回滚后查不到事务日志记录
想从系统视图查“谁在什么时候回滚了什么”，往往一无所获——因为大多数回滚是瞬时的、无痕的。
- SQL Server 的
sys.dm_tran_active_transactions只显示“正在回滚中”的事务，一旦完成就消失；真正可追溯的是fn_dblog()（需开启完整恢复模式+定期备份），但它输出是二进制日志，难读且不推荐线上直接查 - MySQL 没有等效的事务回滚快照视图；
INFORMATION_SCHEMA.INNODB_TRX只反映当前活跃事务，回滚完即清空 - 真正可行的方案是前置埋点：在触发器开头记录
@@SPID、GETDATE()、操作类型和关键参数到审计表；出错时再补一条失败标记——靠日志反推，而非指望系统留痕
复杂点在于：触发器运行在主事务上下文中，没有独立生命周期；它既不能自己 BEGIN TRANSACTION，也不能靠异常自动兜底。所有回滚逻辑必须显式编码，且要覆盖嵌套触发、并发冲突、客户端连接中断等边界情况。最容易被忽略的是——你以为 THROW 就万事大吉，其实没配 SET XACT_ABORT ON，照样白搭。
