关于SQL触发器中事务控制的核心要点：触发器的行为机制在事务管理上与许多人的直觉理解存在显著差异。它并不拥有独立的事务空间，也无法随意调用COMMIT或ROLLBACK。如果站在“函数不应当擅自终结调用它的主进程”这一角度来理解，就会容易许多。
触发器不具备独立的事务上下文
关键在于：触发器本身并不是一个事务单元，它始终运行在触发它的父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——请留意，像TRUNCATE TABLE、CREATE这类DDL操作会触发隐式提交，同样会落入这个陷阱。 - 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来确认。
