mysql触发器内禁止显式或隐式提交事务，包括commit、start transaction、ddl等操作，违者报error 1422；唯一允许的事务控制语句是savepoint；校验失败应使用signal而非rollback。
MySQL触发器里写COMMIT直接报ERROR 1422
这不是语法写错或权限不足，而是 MySQL 内核级硬性限制：触发器必须运行在父 DML 语句（如 INSERT INTO orders）启动的隐式事务中，它自己没有事务控制权。COMMIT 一出现，MySQL 就在解析阶段拒绝创建触发器，或在执行时立刻中断并抛出 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。
常见踩坑点包括：
- 在
BEFORE INSERT里加了COMMIT，建触发器语句直接失败 - 触发器里
CALL log_proc()，而log_proc内部有COMMIT—— 错误堆栈不显示具体在哪一行，只提示触发器上下文违规 - 以为
IF condition THEN COMMIT; END IF;能绕过检查，其实只要语法树里存在COMMIT关键字，就过不了解析
哪些操作会隐式触发COMMIT并同样报错
显式写 COMMIT 只是冰山一角。MySQL 把以下操作都视为“隐式提交”，只要触发器或其调用链中出现任意一项，就会触发同款 ERROR 1422：
-
START TRANSACTION、BEGIN WORK -
TRUNCATE TABLE、CREATE TABLE、ALTER TABLE等 DDL 语句 - 对 MyISAM 表执行
INSERT/UPDATE/DELETE（因 MyISAM 不支持事务） - 调用另一个含上述行为的存储过程（哪怕只嵌套一层）
特别注意：SAVEPOINT 是唯一被允许的事务控制语句，可用于局部回滚，但它不能替代 COMMIT，也不能脱离外层事务独立生效。
Oracle 和 SQL Server 的行为差异
不同数据库对触发器内事务控制的处理逻辑不同，但目标一致：保护事务原子性。
- Oracle 允许用自治事务（
AUTONOMOUS_TRANSACTION）绕过限制，在触发器中开独立事务，但该事务与父事务完全解耦——父事务回滚不影响它，也就意味着日志可能留下而主数据没写入，需谨慎评估一致性风险 - SQL Server 允许写
ROLLBACK TRANSACTION，但它会清空整个外层事务（@@TRANCOUNT归零），且容易引发Error 3609（事务被终止）或Error 266（嵌套调用时事务计数不匹配） - MySQL 和绝大多数云数据库（如阿里云 RDS、腾讯云 CDB）不提供等价机制，禁止就是禁止，无例外
校验失败时别写ROLLBACK，改用SIGNAL
很多人想在校验不通过时“只回滚触发器里的变更”，于是写 ROLLBACK，结果报错 ERROR 1305 (42000): FUNCTION does not exist——这其实是 MySQL 拦截非法事务语句后给出的误导性提示。
正确做法是用 SIGNAL 主动抛异常，让整个父事务回滚：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status transition';
这样既符合事务原子性，又不会破坏锁等待链或复制一致性。真正容易被忽略的是：即使触发器本身没写任何事务语句，只要它调用了含 START TRANSACTION 的存储过程，照样崩。务必逐层检查所有被调用对象的实现细节。
