ERROR 1422 是 MySQL 运行时强制拦截，因触发器必须依附父 DML 事务，禁止任何显式或隐式提交；只要调用链中任意层级含 START TRANSACTION、COMMIT、ROLLBACK、DDL 或 MyISAM 操作，即报此错，且错误归因于触发器上下文。
触发器调用存储过程直接报 ERROR 1422 是什么情况
这不是语法错误，而是 MySQL 在运行时强制拦截：只要触发器执行流进入含 START TRANSACTION、COMMIT、ROLLBACK 的存储过程，立刻抛出 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。根本原因是触发器必须依附于父 DML 事务，不能“偷偷开新事务”或提前提交。
- 哪怕
COMMIT被包在IF条件里，MySQL 解析阶段就拒绝——不等真正执行到那行 - 隐式提交同样触发该错误：操作 MyISAM 表、执行
ALTER TABLE、调用另一个含 DDL 的过程 - 错误堆栈不会指向存储过程内部，只提示“trigger context”，容易误判为触发器本身写错了
为什么嵌套一层也逃不掉检查
MySQL 对事务控制的限制是穿透式的：不仅扫描触发器本体，还会逐层检查所有被 CALL 的存储过程、函数，甚至函数里再调用的函数。只要其中任意一层含禁止语句，整个调用链失败。
-
CALL proc_a()→proc_a内CALL proc_b()→proc_b含START TRANSACTION→ 报错仍归因于触发器上下文 - 即使
proc_a声明为READS SQL DATA，只要实际执行了事务语句，约束依然生效 - 常见误判点：确认触发器和过程里都没写
START TRANSACTION，却仍报错——大概率踩中隐式提交陷阱（如过程里更新了 MyISAM 表）
触发器里能安全调用什么样的存储过程
能稳定 CALL 的存储过程，必须满足“零事务侵入 + 单向写入”原则：只对独立的 InnoDB 日志表做 INSERT，且该表与触发器所在表无关。
- 目标表不能是触发器正在操作的同一张表（否则触发
ERROR 1442） - 参数全部来自
NEW/OLD扁平值，不带子查询或复杂表达式 - 内部不含
ROLLBACK或SIGNAL以外的错误中断逻辑（RESIGNAL可接受） - 不依赖临时表、用户变量、系统变量（如
@@version），MySQL 8.0+ 还需SYSTEM_VARIABLES_ADMIN权限
排查时最容易忽略的三个点
很多问题不是代码写错，而是环境或配置没对齐。查完语法和逻辑后，优先验证这三项：
-
SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'xxx'看STATUS是否为ENABLED；MySQL 5.7 不支持ALTER TRIGGER ... ENABLE，只能重建 -
SHOW CREATE PROCEDURE proc_name查DEFINER用户是否存在、权限是否覆盖过程内所有操作（比如 INSERT 到audit_log就得有对应INSERT权限） -
SELECT @@sql_log_bin必须为1；某些 ORM 或连接池默认设SET SESSION sql_log_bin = 0，导致触发器不执行也不报错
