MySQL触发器禁止START TRANSACTION等显式事务控制语句，因其无独立事务上下文，必须依附父DML事务；隐式提交操作（如MyISAM DML、DDL）同样触发ERROR 1422；仅SAVEPOINT可用；BEFORE/AFTER触发器在数据干预与失败影响上存在本质差异；安全操作限于向独立InnoDB日志表单向写入。
MySQL触发器里写START TRANSACTION会直接报错
不是语法不支持，而是 MySQL 在运行时强制拦截——只要触发器体或它调用的任何存储过程里出现 START TRANSACTION，执行到那一行就会立刻抛出 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。这个检查是穿透式的：哪怕 START TRANSACTION 躲在 CALL proc_a() 调用的第三层子过程中，也会被拦下。
根本原因在于触发器没有自己的事务上下文，它必须依附于父 DML（如 INSERT INTO orders）所处的事务。一旦允许它“开新事务”，就可能造成主语句回滚但触发器已提交，数据状态撕裂。
-
START TRANSACTION、COMMIT、ROLLBACK全部禁止，连BEGIN WORK这类等价写法也不行 -
SAVEPOINT是唯一被允许的事务控制语句，可用于局部回滚，但不能替代提交 - 即使过程里
START TRANSACTION被包在IF FALSE THEN ... END IF里，MySQL 解析阶段就拒绝加载该触发器
哪些操作会隐式触发COMMIT导致同样失败
很多开发者确认没写 COMMIT 却仍报 ERROR 1422，大概率踩中了隐式提交陷阱。MySQL 把以下行为一律视为“破坏事务原子性”，在触发器中执行即崩：
- 对 MyISAM 表做
INSERT/UPDATE/DELETE（MyISAM 不支持事务，每次 DML 都自动落盘） - 执行 DDL，比如
ALTER TABLE、DROP INDEX、CREATE TEMPORARY TABLE - 调用另一个含上述行为的存储过程（嵌套一层就中招，不用真执行到那行）
- MySQL 配置
autocommit=1时，在触发器里执行普通INSERT到非事务表，也可能被当作隐式提交处理
BEFORE 和 AFTER 触发器对事务的影响完全不同
它们不只是执行时机不同，而是决定了你能否干预主语句、以及失败时的数据可见性边界：
-
BEFORE：可读写NEW，能用SIGNAL中止整条语句；若失败，原INSERT/UPDATE根本不会执行 -
AFTER：NEW只读，无法修改原数据；但它的任意语句失败（比如往日志表INSERT冲突），整个外部事务仍会回滚——包括刚插入的那行 - 两者都共享同一个事务 ID、undo log 和隔离快照；你在
AFTER里查SELECT MAX(id)，看到的是未提交值，不是最终落库结果
真正能安全放进触发器的操作只有这几类
别把业务逻辑塞进去。触发器只适合做轻量、无副作用、单向写入的动作：
- 往独立的 InnoDB 日志表（如
audit_log）插入一条记录，且该表与触发器所在表无主外键关联 - 所有字段值来自
NEW/OLD扁平赋值，不带子查询、不查其他表、不调函数 - 不依赖临界状态判断（比如不查
config表决定是否写日志） - 避免
SELECT ... FOR UPDATE或跨表更新，否则极易引发死锁（SHOW ENGINE INNODB STATUS里的死锁链路常被截断）
最常被忽略的一点：哪怕触发器本身空着，只要它 CALL 的存储过程里有一行 ALTER TABLE，整个链路就不可用。检查必须逐层穿透到底层定义。
