mysql 8.0触发器禁止使用任何事务控制语句，且触发器失败会导致整个外部事务回滚；before可修改new并中止主语句，after不可修改但失败仍回滚主事务；日志等非关键操作应移至应用层。
START TRANSACTION、COMMIT、ROLLBACK、SAVEPOINT 全部会直接报错，比如 ERROR 1305 (42000): SAVEPOINT does not exist 或 ERROR 1295 (HY000): This command is not supported in the trigger。这不是配置问题，是内核级硬性限制。
触发器必须依附于外部事务，它本身没有独立事务上下文。想“在触发器里控制事务”，本质上是个误解；真正能做的，是理解它怎么被外部事务裹挟，以及如何规避常见陷阱。
触发器失败会导致整个外部事务回滚
只要触发器执行出错（比如 SIGNAL 报错、违反约束、INSERT 到不存在的表），不仅触发器逻辑中断，原始的 INSERT/UPDATE/DELETE 也会一起回滚。这是默认行为，无法关闭。
-
BEFORE触发器出错 → 原语句根本不会执行（连约束检查都跳过） -
AFTER触发器出错 → 原语句已逻辑完成，但整个事务仍回滚（包括那条刚写的行） - 哪怕只往日志表写一条
INSERT，它失败了，主业务数据也全丢
想“保底写日志”？别依赖触发器本身
如果日志写入失败不能影响主流程（比如审计日志、操作记录），触发器不是可靠载体。MySQL 不允许你在里面做局部回滚或忽略错误。
- 用
INSERT ... ON DUPLICATE KEY UPDATE替代普通INSERT，避免唯一键冲突导致回滚 - 写入非事务引擎表（如
MyISAM）——但该引擎已废弃，不推荐 - MySQL 8.0+ 可考虑
WRITE_ONLY表 + 异步落盘方案，但需额外组件支持 - 更稳妥的做法：把日志逻辑移到应用层，用消息队列解耦
并发下触发器容易引发死锁
触发器内访问其他表时，会按查询路径加锁，和主语句共享事务 ID，但锁获取顺序若不一致，极易形成环路。
- 典型场景：
UPDATE orders触发器查config表 → 同时UPDATE config触发器更新orders_log表 - 监控死锁：执行
SHOW ENGINE INNODB STATUS，看LATEST DETECTED DEADLOCK区域是否含触发器相关表 - 规避方式：所有触发器统一访问顺序（例如总是先查
user再查log），且避免更新高频变更的辅助配置表
BEFORE 和 AFTER 对事务的影响差异很关键
它们不是“执行时机不同”那么简单，而是决定了你能否干预主语句、以及失败时的数据可见性。
-
BEFORE：可读写NEW，能提前修改字段值或用IF ... SIGNAL中止整条语句 -
AFTER：NEW只读，无法改原数据；但它的 DML 操作失败，一样拖垮主事务 - 跨表操作（如更新另一张状态表）放在
BEFORE更易控制，但要注意约束检查顺序（BEFORE在约束前，AFTER在约束后）
START TRANSACTION、设 SAVEPOINT、分段提交，而触发器只适合轻量、确定、无副作用的行级补全操作。
