必须在 before update 触发器中校验状态迁移合法性，通过检查 old.status→new.status 是否属于允许路径，禁止在 after update 中校验以防数据已落盘无法回滚。
触发器里怎么判断订单状态变更是否合法
MySQL 触发器本身不提供状态机建模能力，必须手动编码校验逻辑。核心是：在 BEFORE UPDATE 触发器中，检查 OLD.status → NEW.status 的迁移是否被允许。比如「已取消」不能变回「待支付」，「已完成」不能退回「已发货」。
常见错误是只校验 NEW.status 是否为枚举值，却忽略迁移路径。结果导致数据库里出现逻辑矛盾的状态跳转（如直接从「待支付」到「已完成」）。
- 用
CASE或嵌套IF判断每种合法前驱状态，例如：IF OLD.status = 'pending' AND NEW.status NOT IN ('paid', 'cancelled') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status transition: pending → ' + NEW.status; END IF; - 把所有允许的迁移对写成表（如
order_status_transition），在触发器里用(OLD.status, NEW.status)查询该表是否存在——更易维护，但注意触发器中不能用存储过程调用或动态 SQL，所以得用SELECT ... INTO+NOT FOUND处理 - 避免在触发器里调用函数做校验（除非函数是
DETERMINISTIC且无副作用），否则可能引发复制异常或性能抖动
为什么不能在 AFTER UPDATE 里做状态合法性校验
因为 AFTER UPDATE 触发时，数据已经写入，校验失败也无法回滚当前语句——MySQL 不允许在 AFTER 触发器中执行 SIGNAL 或修改刚更新的行。强行抛错会导致事务中断，但此时变更已落盘，违反原子性预期。
实际场景中，有人误用 AFTER 做日志记录后再校验，结果发现状态非法却无法修复，只能靠外部补偿，反而增加系统复杂度。
- 所有强制性业务规则（尤其是状态约束）必须放在
BEFORE UPDATE -
AFTER UPDATE只适合旁路操作：写审计日志、更新统计字段、发消息通知等不改变主业务数据的动作 - 如果需要在状态变更后联动其他表（如「已完成」时扣减库存），也应先在
BEFORE确保状态合法，再在AFTER安全执行联动
触发器中访问关联表带来的隐性风险
订单状态常需结合订单项、用户等级、支付流水等判断是否允许变更（例如「VIP 用户可取消已发货订单」）。但触发器内查其他表会显著拖慢 UPDATE 性能，且在基于语句的复制（SBR）模式下可能出错。
典型问题：触发器里 SELECT ... FROM payment WHERE order_id = NEW.id，若 payment 表没走索引，单次更新就卡几十毫秒；更糟的是，如果主从复制使用 SBR，而该查询依赖 session 变量或函数，从库执行时结果可能不同。
- 优先将必要字段冗余进订单主表（如
is_vip,payment_status），减少关联查询 - 真要查关联表，确保被查字段有高效索引，并加
FOR UPDATE防止幻读（但会加重锁竞争） - 避免在触发器里调用自定义函数，特别是含
SELECT的函数——MySQL 8.0+ 对此类函数的复制安全性仍有限制
多触发器共存时的执行顺序与冲突
一个表上可以有多个 BEFORE UPDATE 触发器，但 MySQL 不保证它们的执行顺序（除非显式命名并用 CREATE TRIGGER ... FOLLOWS/PRECEDES 控制）。如果两个触发器都试图修改 NEW.status，结果不可预测。
实践中常见踩坑：一个触发器负责状态迁移校验，另一个负责自动填充 updated_at 或 operator_id，但后者意外覆盖了前者设置的错误提示字段，导致校验失效。
- 同一个事件（如
BEFORE UPDATE）下，只保留一个触发器，把所有前置逻辑集中处理 - 若必须拆分，用
FOLLOWS明确依赖关系，例如：CREATE TRIGGER tr_order_status_check BEFORE UPDATE ON orders FOR EACH ROW FOLLOWS tr_order_auto_fields - 不要在触发器里给
NEW.status赋值来“修正”状态（如把非法值转成默认值），这会让调用方误以为操作成功；应该用SIGNAL明确拒绝
