SQL触发器中禁止COMMIT，因其无独立事务上下文，必须依附宿主DML事务；MySQL报ERROR 1422、Oracle报ORA-04092，自治事务（PRAGMA AUTONOMOUS_TRANSACTION）是Oracle唯一合法绕过方式，MySQL则须用SIGNAL中断事务。
SQL触发器里不能用 COMMIT，不是语法写错了，而是数据库内核直接禁止——它根本不允许触发器拥有自己的事务边界。
为什么触发器里一写 COMMIT 就报错
触发器没有独立事务上下文，它运行在宿主 DML（比如 INSERT INTO orders）开启的隐式事务中。所有触发器内的语句（包括 INSERT INTO audit_log）自动绑定到这个事务。一旦你写 COMMIT，数据库就无法保证后续主语句是否成功，强行提交会导致原子性破坏。
- MySQL 直接在解析阶段拦截，建触发器时就报
ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger - Oracle 报
ORA-04092: cannot commit in a trigger，哪怕用EXECUTE IMMEDIATE 'COMMIT'也过不了编译 -
TRUNCATE TABLE、CREATE INDEX、ALTER TABLE这类 DDL 同样会隐式提交，同样触发相同错误 - 连
ROLLBACK和SAVEPOINT都被禁止，因为它们都在试图定义事务边界
MySQL 中正确中止非法操作：用 SIGNAL 替代 ROLLBACK
很多人想“只回滚触发器里的操作”，于是写 ROLLBACK，结果报错。其实触发器没法局部回滚——它必须和主语句共进退。正确做法是抛异常，让整个事务失败并自动回滚。
- 仅限 MySQL 5.5+，低版本不支持
SIGNAL - 必须放在
BEFORE触发器中，才能阻止主语句执行 - 示例：校验金额非负
IF NEW.amount < 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount cannot be negative'; END IF;
- 注意：
SIGNAL不会提交或回滚任何数据，它只是中断执行流，由 MySQL 自动回滚整个事务 - 别在
AFTER触发器里用SIGNAL，此时主语句已执行，再抛异常也无法撤回
Oracle 中唯一合法绕过方式：声明 PRAGMA AUTONOMOUS_TRANSACTION
如果真需要在触发器里持久化日志、调用外部服务或写审计表，Oracle 允许开启自治事务——它是一个完全隔离的新事务，和主事务互不影响。
- 必须紧贴
DECLARE后第一行，中间不能有空行或注释 - 自治事务内必须显式写
COMMIT或ROLLBACK，否则退出时自动回滚（日志全丢） - 它有自己的 undo log、SCN、锁空间，
SELECT FOR UPDATE不会阻塞主事务 - 误用风险高：比如在自治事务里调用
UTL_HTTP.request，请求发出后主事务回滚也撤不回来
CREATE OR REPLACE TRIGGER log_order_insert
BEFORE INSERT ON orders
FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION; -- 必须第一行
BEGIN
INSERT INTO audit_log (msg) VALUES ('order inserted');
COMMIT; -- 必须手动提交
END;跨数据库通用避坑要点
不同数据库对触发器的限制逻辑一致，但实现细节容易踩雷：
- MySQL 不允许触发器调用含
START TRANSACTION的存储过程，哪怕触发器本身没写事务语句，建的时候就失败 - PostgreSQL 虽支持
RETURNING，但不能靠它在触发器里驱动下游状态变更；想异步处理得用dblink或外部监听，复杂度陡增 - 所有数据库都禁止对同一张表做递归 DML：比如
AFTER INSERT ON t里又UPDATE t，MySQL 直接报ERROR 1442 - 看似安全的操作可能暗藏陷阱：
SELECT ... FOR UPDATE在触发器里可能引发锁等待超时，但错误堆栈不体现根源
真正安全的触发器，只该做轻量、无副作用、不越界的校验与状态赋值；任何涉及外部系统、跨库写入、复杂查询或事务控制的动作，都应该移出触发器，交给应用层或定时任务处理。
