触发器调用含START TRANSACTION的存储过程会直接报ERROR 1422，因MySQL强制要求触发器依附于父DML事务，禁止任何显式或隐式事务操作，该限制穿透整个调用链，包括被调用过程及其嵌套层级。
触发器调用含START TRANSACTION的存储过程会直接报ERROR 1422
MySQL在触发器执行期间禁止任何显式或隐式事务控制操作，而START TRANSACTION正是被硬性拦截的语句。哪怕它藏在被CALL的存储过程中，只要触发器执行流进入该过程体，就会立刻触发ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。这不是语法解析失败，而是InnoDB在运行时对上下文事务状态的强制校验——触发器必须依附于父DML语句的事务，不能“偷偷开新事务”。
为什么嵌套调用也逃不过检查？
MySQL对事务控制的限制是穿透式的：不仅检查触发器本体，还会逐层扫描所有被调用的存储过程、函数，甚至函数里再调用的函数。只要其中任意一层含START TRANSACTION、COMMIT、ROLLBACK，或执行了会导致隐式提交的操作（如修改MyISAM表、执行DDL），整个调用链就失败。
-
START TRANSACTION在存储过程中本身就不合法，它只允许出现在客户端连接层 - 触发器中
CALL proc_a()，而proc_a里又CALL proc_b()，只要proc_b含事务语句，报错仍归因于触发器上下文 - 即使
proc_a声明为READS SQL DATA，只要内部实际执行了START TRANSACTION，约束依然生效
常见误判点：以为“没写START TRANSACTION就安全”
很多开发者确认触发器和被调用过程里都没写START TRANSACTION，却仍报ERROR 1422。这时大概率踩中了隐式提交陷阱：
- 存储过程中执行了
CREATE TEMPORARY TABLE、ALTER TABLE等DDL语句 → 隐式提交当前事务 - 过程里更新了MyISAM引擎的表 → MyISAM不支持事务，每次DML都自动提交
- 过程调用了另一个含
SELECT ... FOR UPDATE的子过程，且该子过程又被定义在触发器触发的同一张表上 → 触发ERROR 1442，但错误传播路径可能被掩盖为1422 - MySQL配置了
autocommit=1，而过程内又没显式START TRANSACTION包裹，导致DML被立即落库，破坏原子性预期
真正能安全调用的存储过程长什么样？
能在触发器里稳定CALL的存储过程，必须满足“零事务侵入+单向写入”原则：
- 只对独立的InnoDB日志表做
INSERT（如audit_log），且该表与触发器所在表无关 - 不查不改触发器所属表及其关联主外键表（避免
ERROR 1442） - 参数全部来自
NEW/OLD扁平值，不带子查询或复杂表达式 - 内部不含
SIGNAL以外的错误中断逻辑（RESIGNAL可接受，ROLLBACK不行） - 不依赖临时表、不执行DDL、不调用含锁语句的其他过程
最易被忽略的是：哪怕过程逻辑再简单，只要它曾被用于其他非触发器场景并悄悄加了START TRANSACTION，迁移到触发器环境就必须剥离——事务边界从来不在数据库对象内部，而在应用发起的那一行START TRANSACTION。
