BEFORE触发器可修改NEW行实现数据干预，AFTER触发器中NEW和OLD均为只读；执行顺序为BEFORE→主操作→AFTER，任一阶段失败均导致事务回滚。
BEFORE 触发器能改数据，AFTER 不能——这是最常踩的坑
你在 AFTER INSERT 或 AFTER UPDATE 里写 SET NEW.amount = NEW.amount * 1.1？MySQL 会直接报错：ERROR 1362 (HY000): Updating of NEW row is not allowed in after trigger。因为 NEW 在 AFTER 中是只读的；而 BEFORE 中你可以安全赋值，这些修改会真正落库。比如想给新订单自动补默认状态、修正金额精度、或拦截非法值，必须用 BEFORE。
- BEFORE：可读写
NEW（INSERT/UPDATE），不可写OLD；可用于校验、默认值填充、字段转换 - AFTER：
NEW和OLD均只读；适合记录日志、更新统计表、发消息通知等“事后动作” - DELETE 场景下，只有
OLD可用，且始终只读——无论 BEFORE 还是 AFTER
执行顺序决定能不能“干预主操作”
MySQL 的触发器不是并行跑的，而是严格按阶段嵌入 DML 生命周期：先跑所有匹配的 BEFORE 触发器 → 真正执行你的 INSERT/UPDATE/DELETE → 再跑所有匹配的 AFTER 触发器 → 最后提交事务。中间任一环节出错，整个语句回滚。
- BEFORE 触发器失败（比如
SIGNAL SQLSTATE '45000'）→ 主 SQL 不执行，不写入数据 - AFTER 触发器失败 → 主 SQL 已成功，但事务整体回滚（对 InnoDB 表）→ 数据“看似插入了”，实则被撤回
- 如果你在 AFTER 里更新关联表，又恰好那个表也有触发器，得注意嵌套深度限制（默认
max_sp_recursion_depth=0，即禁用递归）
什么时候必须用 BEFORE，什么时候只能选 AFTER
核心判断标准就一条：你要做的事，是否依赖主操作已落地的数据？
- 要设默认值、修正字段、阻止非法插入 → 必须 BEFORE（例如：没填
created_at就自动SET NEW.created_at = NOW()） - 要记操作日志、更新商品库存、调用外部系统回调 → 只能 AFTER（因为库存扣减必须等订单真正插入成功后才安全）
- UPDATE 场景下，若需对比“状态是否真变了”，用
IF OLD.status NEW.status THEN ...——这个判断在 BEFORE 和 AFTER 都可行，但修改动作只能放 BEFORE
一个典型错误：以为 AFTER 能“反向修正”主表数据
有人写 AFTER UPDATE 想“如果金额超限就回滚到旧值”，这是徒劳的。AFTER 里连 NEW 都不能改，更别说改表了。真要实现这种逻辑，得在 BEFORE 里做判断+赋值，或者干脆用应用层控制。
另外注意：同一张表上，不能同时存在两个相同类型和时机的触发器（比如两个 BEFORE INSERT），否则创建失败。还有，触发器不支持临时表、视图，也不能返回结果集——它只是安静地执行，不声不响地影响数据流。
