触发器无独立事务上下文，其操作与父dml共享同一事务id、undo log和隔离快照；显式commit/rollback均报错；oracle可通过自治事务绕过，mysql和sql server无等价机制；非dml操作不参与事务控制。
触发器没有独立事务上下文
触发器不是独立事务单元，它运行在父 DML 语句（如 INSERT、UPDATE）所启动的事务中。所有操作——包括触发器里的 INSERT INTO log_table 或 UPDATE counter ——都共享同一个事务 ID、同一份 undo log 和隔离快照。这意味着你无法在触发器里“另起炉灶”提交或回滚，就像不能在函数里擅自结束调用它的那个进程一样。
显式 COMMIT/ROLLBACK 会直接报错
不同数据库报错不同，但本质一致：
- MySQL 报
ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger—— DDL（如TRUNCATE TABLE）、CREATE等隐式提交操作也会触发此错 - Oracle 报
ORA-04092: cannot commit in a trigger—— 即使是EXECUTE IMMEDIATE 'TRUNCATE ...'这种间接 DDL 也因隐式提交而失败 - SQL Server 允许写
ROLLBACK TRANSACTION，但它会清空整个外层事务（@@TRANCOUNT归零），且可能引发错误3609或266，尤其当触发器被嵌套调用时
想“局部提交日志”只能靠自治事务（Oracle）或应用层解耦
Oracle 提供 PRAGMA AUTONOMOUS_TRANSACTION 作为唯一合法绕过方式，但它不是“子事务”，而是真正隔离的新事务：
- 必须在声明区第一行写
PRAGMA AUTONOMOUS_TRANSACTION; - 必须手动
COMMIT或ROLLBACK，否则退出时自动回滚（日志全丢） - 自治事务里调用的存储过程，若没加同样
PRAGMA，仍属于该自治事务，不是新事务 - MySQL 和 SQL Server 没有等价机制；想持久化审计日志又不依赖主事务，只能把日志写入临时表、或移出触发器，改由应用层统一处理
真正容易被忽略的点：非 DML 操作根本不在事务保护范围内
你以为在触发器里 xp_cmdshell 写了文件、PRINT 输出了日志、CLR 调用了 HTTP 接口——这些动作压根不进事务调度器视野。它们执行即生效，ROLLBACK 对其完全无效。更隐蔽的是：触发器里哪怕只做了一次 SELECT FOR UPDATE 或 LOCK TABLES，也可能隐式提交当前事务，导致前面所有变更提前落盘。事务是否真正在跑，得靠 SHOW ENGINE INNODB STATUS 或 DBCC OPENTRAN 实锤，不能凭感觉判断。
