报ERROR 1422，因触发器依附于父DML语句的隐式事务，禁止显式事务控制（如START TRANSACTION）以保障原子性；唯一允许的事务操作是SAVEPOINT。
MySQL触发器里执行START TRANSACTION会报ERROR 1305
触发器中显式开启事务（如写 START TRANSACTION 或 BEGIN）会直接失败，报错 ERROR 1305 (42000): PROCEDURE xxx does not exist 或更明确的 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。这不是语法错误，而是InnoDB对触发器运行上下文的硬性限制。
根本原因在于：触发器不是独立执行单元，它必须依附于外部DML语句所在的事务。MySQL不允许在已存在事务的上下文中再启动新事务——哪怕只是逻辑上的嵌套。
-
START TRANSACTION会隐式触发COMMIT当前事务（如果存在），这与触发器“必须原子执行”的设计冲突 - 哪怕用
SAVEPOINT也无效：触发器内允许SAVEPOINT和ROLLBACK TO SAVEPOINT，但不能RELEASE SAVEPOINT或做任何影响事务状态的操作 - 调用的存储函数若含
START TRANSACTION，同样会触发 ERROR 1422，哪怕该函数本身没被标记为READS SQL DATA
BEFORE/AFTER触发器都共享父事务的锁和生命周期
你执行一条 INSERT INTO orders ...，它触发了一个 AFTER INSERT 触发器，里面有一句 UPDATE user_points SET balance = balance + 10 WHERE user_id = NEW.user_id——这句UPDATE不是“新事务里的操作”，它和原始INSERT共用同一个事务ID、同一组行锁、同一个提交/回滚命运。
这意味着：
- 如果触发器里的UPDATE卡在等某行锁，整个INSERT也会一起卡住，直到
innodb_lock_wait_timeout超时 - 触发器中任何失败（比如违反外键、唯一约束），都会导致原始INSERT回滚，应用层看到的是INSERT失败，而不是“触发器出错了”
- 无法在触发器里做“局部回滚”：
ROLLBACK是禁止的，ROLLBACK TO SAVEPOINT只能回滚触发器内自己设的点，不影响父事务已做的修改
替代方案：用应用层事务或异步任务解耦
当业务逻辑确实需要独立事务边界（比如更新积分失败不应让订单插入失败），就别硬塞进触发器。常见可行路径：
- 把触发器逻辑移到应用层，在同一个应用事务中按需控制：先INSERT订单，再UPDATE积分表，用try/catch捕获异常并决定是否回滚整笔事务
- 用消息队列（如Kafka、RabbitMQ）将积分更新转为异步任务，订单表INSERT成功即发消息，由消费者服务处理，彻底脱离原事务
- 若必须保留在数据库侧，可改用
EVENT定时扫描未处理订单（加状态字段标记），但要注意延迟和重复消费问题
尤其注意：不要用临时表+循环INSERT模拟“事务隔离”——这只会把锁竞争从行级放大到表级，且无法解决根本的事务嵌套限制。
调试时容易忽略的隐式事务陷阱
有些操作看似不涉及事务，实则会偷偷触发隐式提交，进而让触发器失效或行为异常：
-
ALTER TABLE、DROP TABLE、CREATE INDEX等DDL语句会强制提交当前事务，若正在执行的INSERT触发了触发器，而此时另一个连接执行了DDL，可能造成触发器中途被中断 - 使用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE会加锁，但它们本身不开启事务；若在触发器中执行，会延长父事务锁持有时间，极易引发死锁（尤其配合无索引WHERE条件时） - MySQL 8.0+ 的
SET PERSIST或修改系统变量也可能隐式提交，虽不常见，但在自动化运维脚本中要警惕
真正难排查的，往往不是语法报错，而是触发器“静默跳过”或“锁住整个表却不报错”——这时候得查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS，而不是只盯错误日志。
