ERROR 1422 的真实触发点是存储过程内部的隐式提交行为，而非 CALL 语法本身；只要过程含 INSERT、TRUNCATE、CREATE TEMPORARY TABLE、ALTER TABLE 或操作 MyISAM 表等任一隐式提交操作，触发器即报错。
ERROR 1422 的真实触发点不是 CALL 语法，而是存储过程内部行为
MySQL 允许在触发器里写 CALL my_proc()，语法完全合法。报错 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger 并非因为“不能调用”，而是被调用的 my_proc() 在执行过程中触发了隐式提交——哪怕它只有一行 INSERT、一个 TRUNCATE TABLE、甚至只是创建了临时表（CREATE TEMPORARY TABLE），都会让 MySQL 在解析阶段就拒绝该触发器生效。
常见误判点：
- 以为“没写 COMMIT 就安全”，但
ALTER TABLE、DROP VIEW、TRUNCATE这些 DDL 都会强制隐式提交，且无法绕过 - 在存储过程中调用了另一个含 DML 的过程，形成间接隐式提交链，错误堆栈不体现源头
- 过程里用了 MyISAM 表（哪怕只是 SELECT），也会因引擎不支持事务而触发隐式提交
为什么 BEFORE 触发器里调用含 SELECT FOR UPDATE 的过程也报错？
这不是事务控制问题，而是表访问冲突。在 BEFORE INSERT ON orders 中，MySQL 已对 orders 表加了行级锁或意向锁；此时若被调存储过程再去执行 SELECT * FROM orders WHERE id = NEW.id FOR UPDATE，就会触发锁等待或直接报错 ERROR 1205（死锁）或 ERROR 1442（表已被使用）。
关键限制在于：MySQL 不允许触发器上下文（含其调用链）中出现“同一张表被主语句 + 触发器 + 存储过程三方同时访问”的情况，无论读写。
安全做法：
- 避免在过程里查触发器所在表本身，哪怕加
LIMIT 1或WHERE id = NEW.id - 如需关联数据，改用 JOIN 或子查询内联到触发器体中，而非封装进过程
- 确需跨表读取时，目标表必须与触发器表物理隔离（不同库、不同名），且不能是 MyISAM
哪些操作看似无害，实则一碰就崩？
最容易被忽略的是“伪安全”操作：它们不报错、不抛异常，却悄悄破坏事务一致性。
TRUNCATE TABLE tmp_log → 替换成 DELETE FROM tmp_log 才安全
CREATE TEMPORARY TABLE t1 AS SELECT ... → 临时表创建即隐式提交，哪怕后续没 DML
SET @sql = 'ALTER TABLE ...'; PREPARE stmt FROM @sql; EXECUTE stmt; → 动态执行 DDL 同样触发隐式提交，且发生在 EXECUTE 阶段，难以拦截
验证是否已崩的方法：
- 执行前查
SELECT @@in_transaction，值应为 1 - 执行疑似操作后立刻再查，若变为 0（MySQL 8.0+）或
information_schema.INNODB_TRX中无记录，说明事务已被切开 - 应用层用
conn.in_transaction（PyMySQL / mysql-connector-python）打点监控更早暴露问题
真正能复用的逻辑，该放哪？
别纠结“怎么让 CALL 成功”，先判断逻辑本质：
- 纯计算类（格式化时间、拼接字符串、校验邮箱）→ 封装成
FUNCTION，触发器里用SELECT my_format_func(NEW.email)安全调用 - 跨表写入类（记日志、更新统计值）→ 直接内联写进触发器体，别封装；否则要么报错，要么拖慢主流程
- 发通知、调外部 API、归档冷数据 → 这类操作根本不该放在触发器里，会阻塞业务 SQL；应由应用监听 binlog 或走消息队列
- 复杂逻辑、需调试、要返回状态 → 放存储过程，由应用显式调用，而不是塞进触发器
最危险的不是报错，而是你以为事务还“活着”，其实它已经被 DDL 或 TRUNCATE 默默提交了——数据落库不可逆，ROLLBACK 彻底失效。
