使用 FOLLOWS 或 PRECEDES 明确同一事件多个触发器的先后关系

同一张表上有多个 BEFORE UPDATE 触发器时，MySQL 默认按创建顺序执行；如果业务要求“先规范化，再记录审计”，不要把希望寄托在建表脚本的排列上。创建后续触发器时，用 PRECEDES 已有触发器 或 FOLLOWS 已有触发器 把关系写进定义，并且只在相同事件、相同动作时机的触发器之间排序。

先固定触发器的事件与时机

我在维护订单表时，常见的拆分是：一个触发器把状态值规范化，一个记录更新时间，另一个根据行值更新派生字段。这几个动作如果都绑定在 BEFORE UPDATE，就处于同一排序组；BEFORE INSERT、AFTER UPDATE 即使作用于同一张表，也不应拿来和它们比较先后。

先把边界写成清单，再决定顺序：

另外，BEFORE 触发器可以通过 SET NEW.col_name = value 修改即将写入的值，这正是“规范化”应放在前面的原因。AFTER 阶段行变化已经发生，不适合再改写 NEW。

用 FOLLOWS 或 PRECEDES 把顺序写进定义

下面的例子把三个动作拆开：先规范状态，再记录审计时间，最后计算摘要。每个代码块都保留中文注释，便于后续维护者知道排序关系不是偶然的创建顺序。

-- 先创建同一排序组中的第一个触发器，负责规范状态值
CREATE TRIGGER normalize_status
BEFORE UPDATE ON orders
FOR EACH ROW
SET NEW.status = LOWER(TRIM(NEW.status));

-- 明确放在 normalize_status 之后，避免审计动作读取未规范的状态
CREATE TRIGGER audit_changed_at
BEFORE UPDATE ON orders
FOR EACH ROW FOLLOWS normalize_status
SET NEW.changed_at = CURRENT_TIMESTAMP;

-- 明确放在 audit_changed_at 之后，最后计算依赖前面结果的摘要
CREATE TRIGGER rebuild_summary
BEFORE UPDATE ON orders
FOR EACH ROW FOLLOWS audit_changed_at
SET NEW.summary = CONCAT(NEW.status, ':', NEW.changed_at);

如果是后来发现某个新动作必须插到最前面，可以改用 PRECEDES normalize_status。关键字后面引用的是已经存在、且属于同一事件和时机的触发器名；它不是任意注释，也不是给触发器起新的排序编号。

发布后用定义和最小更新复核

不要只看迁移文件的文本顺序。上线后先查看关键触发器定义，再用一行测试数据检查最终字段是否符合预期：

-- 读取定义，确认排序子句和目标表没有被误改
SHOW CREATE TRIGGER audit_changed_at;
SHOW CREATE TRIGGER rebuild_summary;

-- 从元数据表按名称列出同表触发器，作为维护清单
SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING, ACTION_STATEMENT
FROM INFORMATION_SCHEMA.TRIGGERS
WHERE TRIGGER_SCHEMA = DATABASE()
  AND EVENT_OBJECT_TABLE = 'orders'
ORDER BY ACTION_TIMING, EVENT_MANIPULATION, TRIGGER_NAME;

-- 用事务包住最小更新，便于发现字段依赖顺序不对时回滚测试数据
START TRANSACTION;
UPDATE orders SET status = ' PAID ' WHERE id = 1001;
SELECT id, status, changed_at, summary FROM orders WHERE id = 1001;
ROLLBACK;

这里的查询结果适合做人工复核清单，但不要把按名称排序的查询结果误当成执行顺序证明；真正的排序关系应以每个触发器的定义为准。若某个 BEFORE 触发器报错，触发它的整条语句会失败；对事务表而言，语句产生的改动也会回滚。

重建和维护时的三个边界

1. 删除被引用的触发器前先改链路。 如果后续部署仍声明 FOLLOWS 或 PRECEDES 指向已删除对象，迁移脚本就会失去明确的参照。
2. 同一动作不要拆成隐式依赖。 让摘要触发器依赖审计触发器的字段时，应在定义和文档中说明依赖；否则单独重建其中一个触发器容易改变行为。
3. 多行 UPDATE 也按行触发。 触发器主体是 FOR EACH ROW，测试时要覆盖多行更新和失败回滚，不能只验证一行的偶然结果。

常见问题

FOLLOWS 和 PRECEDES 能不能跨 BEFORE、AFTER 使用？

不能。它们用于同一表、同一事件、同一动作时机中的已有触发器；跨组时应重新设计链路。

不写排序子句时，顺序是不是永久稳定？

默认按创建顺序执行，但重建、迁移和恢复可能改变创建历史。需要长期稳定的依赖，应显式写出 FOLLOWS 或 PRECEDES。

为什么查 INFORMATION_SCHEMA 后还要看 SHOW CREATE TRIGGER？

元数据表适合盘点对象和绑定事件，SHOW CREATE TRIGGER 更适合确认具体定义中的排序子句，两者用途不同。

把触发器看成一条有边界的数据处理链：先确认同组，再声明相邻关系，最后用定义和事务测试复核。这样新增审计或派生逻辑时，顺序就不会只存在于某次部署的时间线上。