为什么MySQL 5.7中不能在触发器里调用存储过程

根本原因是MySQL禁止触发器中任何隐式提交操作，绝大多数存储过程含DML或事务语句会触发隐式提交，违反原子性约束而报ERROR 1422；同时更新被触发表本身会触发ERROR 1442，属表级锁定保护机制。

根本原因不是语法禁止，而是MySQL在触发器执行期间禁止任何隐式提交操作——而绝大多数存储过程都会触发隐式提交，直接违反这条铁律。

ERROR 1422 的真实触发条件

当你在触发器里写 CALL my_proc()，MySQL报错 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger，这不是因为“不支持CALL”，而是因为：my_proc() 内部哪怕只有一行 INSERT、UPDATE、DELETE，或显式/隐式用了 START TRANSACTION、COMMIT、TRUNCATE，甚至调用含DML的其他存储过程，都会导致隐式提交。

• 哪怕存储过程只查数据（SELECT），只要它内部用了临时表（CREATE TEMPORARY TABLE），也会触发隐式提交
• 函数（FUNCTION）不受此限，但函数不能执行DML，也不能返回结果集
• SELECT ... INTO 是安全的，但 SELECT 直接返回结果集会触发 ERROR 0A000

为什么AFTER INSERT里NEW.id可用，却仍不能调用更新原表的存储过程？

能读 NEW.id 和能改原表是两回事。AFTER INSERT 触发器确实能访问完整 NEW 记录，包括自增ID，但这只是“读”；一旦你试图在存储过程中执行 UPDATE orders SET status = 'done' WHERE id = NEW.id，就触犯了另一条规则：ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。

• 这个错误和事务提交无关，是MySQL的表级锁定保护机制
• 即使存储过程只更新其他字段（非主键），只要目标表和触发器所在表是同一张，就会被拦住
• 绕过方式只有：把DML挪到下游表（如 order_logs）、用应用层异步处理、或改用事件调度器（EVENT）延后执行

想复用逻辑，到底该往哪放？

别纠结“怎么让触发器CALL成功”，先判断逻辑本质：

• 纯计算（比如格式化时间、拼接字符串、校验邮箱格式）→ 封装成 FUNCTION，触发器里用 SELECT my_format_func(NEW.email) 安全调用
• 涉及跨表写入（如记录日志、更新统计值）→ 直接内联写进触发器体，别封装；否则要么报错，要么拖慢主流程
• 需要发通知、调外部API、归档冷数据 → 这类操作根本不该放在触发器里，会阻塞业务SQL；应由应用层监听binlog或用消息队列解耦
• 逻辑复杂、需调试、要返回状态 → 放存储过程，由应用显式调用，而不是塞进触发器

真正难的不是语法绕过，而是区分清楚：哪些事必须“立刻、强制、同步”做（适合触发器），哪些事只是“顺手、可延、可丢”做（必须移出）。硬塞只会让错误更隐蔽、回滚更不可控。