触发器中调用含COMMIT或隐式提交操作（如DDL、LOCK TABLES、CREATE TEMPORARY TABLE等）的存储过程必报ERROR 1422，因MySQL禁止在触发器中破坏事务原子性，唯一解法是将事务逻辑移出触发器。
触发器里CALL含COMMIT的存储过程必报ERROR 1422
MySQL直接拒绝执行，错误信息是ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。这不是权限或语法问题，而是InnoDB内核级限制：触发器必须运行在父DML语句的事务上下文中，不能破坏事务原子性。
常见现象包括：
- 建触发器时
CALL my_proc()就失败，但错误堆栈不指明具体哪行 - 触发器创建成功，第一次INSERT触发时报错，且主语句也跟着失败
- 存储过程本身在单独调用时完全正常，一被触发器调用就崩
隐式提交比显式COMMIT更难察觉
你以为只写了DML，其实已经踩雷。以下操作在存储过程中只要存在，被触发器调用就会触发ERROR 1422：
-
ALTER TABLE、DROP DATABASE等DDL语句（会强制提交当前事务） -
CREATE TEMPORARY TABLE（部分MySQL版本中会隐式提交） -
LOCK TABLES或UNLOCK TABLES - 调用另一个含上述任一操作的存储过程（递归检查，不限层级）
- 某些配置下的
LOAD_FILE()或SYS_EXEC()也可能触发
最危险的是：这些语句在独立执行时不报错，一旦嵌套进触发器上下文，就立刻让整个父事务中断。
为什么不能“绕过”而只能“重构”
MySQL不提供例外通道，所有试图绕开的尝试（比如用SAVEPOINT包裹、改用READS SQL DATA声明、或加DETERMINISTIC）都无效。根本约束是：
- 触发器不是独立执行单元，它和原始
INSERT/UPDATE共享同一个事务ID、同一组undo log、同一份隔离快照 - 如果允许它开启新事务，主表写入成功但触发器事务失败，数据库将处于无法回滚到一致状态的中间态
- 主从复制场景下，从库重放时可能因执行顺序/锁等待差异导致行为不一致，引发数据漂移
所以唯一可靠的做法是把事务逻辑移出触发器：要么合并进应用层事务，要么拆成异步任务（如发MQ消息），或者用定时扫描+状态字段兜底。
最容易被忽略的调用链陷阱
你检查了存储过程本身没写COMMIT，却忘了它内部CALL了另一个过程——哪怕只嵌套一层，只要下游过程含START TRANSACTION或ALTER TABLE，整个调用链就失效。
调试建议：
- 用
SHOW CREATE PROCEDURE proc_name逐层展开，确认每一层都不含DDL、锁语句、事务控制 - 把过程逻辑复制到触发器体中内联执行（避免CALL），虽然冗余但最可控
- 若必须复用，改用无副作用的自定义函数（
FUNCTION），注意输出参数需经用户变量中转（如@tmp_val）
真正安全的触发器，只做字段补全、简单日志写入、或往独立InnoDB审计表插入——任何涉及多表协调、状态校验、外部依赖的操作，都不该放在里面。
