触发器中调用含START TRANSACTION的存储过程会报ERROR 1422，因触发器依附于父DML语句的隐式事务，禁止显式事务控制以保证原子性；唯一允许的事务操作是SAVEPOINT。
MySQL触发器里调用含 START TRANSACTION 的存储过程会报什么错
直接执行会触发 ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger。这不是语法错误，而是 MySQL 的硬性事务约束——触发器运行在父语句的隐式事务上下文中，不允许任何显式事务控制语句（START TRANSACTION、COMMIT、ROLLBACK）介入。
为什么触发器不能有自己的事务边界
触发器不是独立执行单元，它依附于 DML 语句（如 INSERT、UPDATE），而该语句本身已处于一个不可分割的事务阶段。MySQL 要求整个触发链与原始语句原子性一致：要么全部成功，要么全部回滚。如果允许触发器内开新事务，就破坏了这种一致性——比如触发器里的 COMMIT 提交了部分变更，但主语句后续失败，数据库状态就无法恢复到一致点。
- 触发器执行时，
autocommit被强制设为 0，且禁止修改 -
SAVEPOINT是唯一被允许的事务控制操作（仅限某些版本） - 即使存储过程本身合法，只要它内部有
START TRANSACTION，被触发器调用即触发限制
绕过限制的可行方案
不能“绕过”限制，但可以重构逻辑来适配约束：
- 把需要事务保护的操作拆出来，改由应用层或事件调度器（
EVENT）驱动，避开触发器上下文 - 用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO替代部分需事务协调的写逻辑 - 若只是想保证多表写入原子性，把相关 DML 合并在触发器内完成（不调用外部过程），MySQL 会自动将其纳入父事务
- 用
GET_LOCK()+ 应用层重试模拟轻量级互斥，避免对事务控制的依赖
注意：CREATE PROCEDURE 声明中的 READS SQL DATA 或 MODIFIES SQL DATA 不影响该限制，只影响函数能否在 SELECT 中调用。
容易被忽略的隐式提交场景
除了 START TRANSACTION，以下操作在触发器中同样非法：
-
ALTER TABLE、DROP DATABASE等 DDL 语句（会隐式提交） -
LOCK TABLES/UNLOCK TABLES - 调用另一个包含上述任一操作的存储过程（递归检查，不限层级）
- 甚至某些系统函数如
LOAD_FILE()在特定配置下也可能触发隐式提交
最稳妥的做法是：触发器里只做简单数据校验、字段补全、日志记录（写入非事务表如 MyISAM 或用 INSERT DELAYED），所有复杂协调逻辑移交到应用或定时任务中处理。
