MySQL 5.7+ 触发器可调用存储过程，但禁止修改同一张表；需用NEW/OLD显式传参；AFTER INSERT中NEW.id可用且准确；事务回滚时触发器及所调存储过程的DML自动回滚。
触发器里不能直接调用存储过程？错，但有限制
MySQL 5.7+ 允许在 BEFORE 和 AFTER 触发器中用 CALL 调用存储过程，但有硬性约束：不能在触发器里调用修改**同一张表**的存储过程（会报 ERROR 1442）。比如 orders 表的 INSERT 触发器里，若存储过程内部又执行 INSERT INTO orders，MySQL 直接拒绝。
实操建议：
- 把写操作拆到「下游表」——比如触发器调用
log_order_created()，它只往order_logs插入记录，不碰orders - 用
INSERT ... SELECT或临时表绕过限制，但要小心事务可见性问题 - 如果必须更新原表，改用应用层异步处理，别硬塞进触发器
存储过程传参太弱？用触发器变量补位
触发器没有“参数”概念，但能访问 NEW 和 OLD 伪记录。想把字段值传给存储过程，得显式提取并作为参数传入，不能直接传 NEW 整体。
常见错误现象：写 CALL update_cache(NEW) —— MySQL 报 ERROR 1318（参数数量/类型不匹配）。
实操建议：
- 按需传具体字段：
CALL update_cache(NEW.order_id, NEW.status, NEW.updated_at) - 避免传大字段（如
TEXT），可能拖慢触发器执行，甚至锁表 - 如果字段多且固定，可在存储过程中用默认值兜底，减少触发器侧适配成本
AFTER INSERT 触发器里读不到自增 ID？要看时机
在 AFTER INSERT 触发器里，NEW.id 是可用的——前提是该列是 INT AUTO_INCREMENT 且未被显式赋值。但如果插入时指定了 id 值（如 INSERT INTO t(id, name) VALUES (100, 'a')），NEW.id 就是那个指定值，不是生成的新 ID。
性能影响：依赖 NEW.id 做后续关联（比如写日志、发消息），只要没额外查表，基本无开销；但若在触发器里再查一次 SELECT LAST_INSERT_ID()，反而多余且可能出错。
实操建议：
- 优先用
NEW.id，它最准、最快 - 别在触发器里调
LAST_INSERT_ID()—— 它返回的是当前会话最后一条INSERT的 ID，不一定是本条 - 批量插入（
INSERT ... VALUES (...), (...)）时，每个NEW.id都对应各自行，安全
事务回滚时，触发器调用的存储过程会一起撤回吗？
会。触发器和它调用的存储过程都运行在同一个事务上下文中。只要主语句（如 INSERT）最终回滚，触发器里的 CALL、存储过程内的所有 DML 都自动回滚，无需手动干预。
容易踩的坑：
- 存储过程中用了
START TRANSACTION或COMMIT—— 会报ERROR 1305（函数不存在）或直接中断，MySQL 不允许在触发器/存储过程中显式控制事务 - 调用了非事务引擎表（如
MyISAM），它的修改不会回滚，造成数据不一致 - 过程里调了外部服务（如 HTTP 请求），这部分无法回滚，得靠补偿逻辑，别指望数据库兜底
复杂点在于：你得清楚哪些操作是事务性的，哪些不是。数据库只管自己的表，管不了你的 curl 或 Kafka 生产者。
