mysql中触发器的执行顺序与控制

来源：这里教程网时间：2026-02-28 20:44:12 作者：

触发器执行顺序由类型和定义顺序共同决定

MySQL 中同一事件（如

INSERT

）上可以定义多个触发器，但它们的执行顺序不是随机的：先执行

BEFORE

类型，再执行

AFTER

类型；同为

BEFORE

或同为

AFTER

时，按创建时间升序执行（即先建的先触发）。没有显式控制执行优先级的语法（比如

DEFINER

或

ORDER

子句），

CREATE TRIGGER

语句本身不支持指定顺序。

无法用 SQL 直接修改已有触发器的执行顺序

MySQL 不提供

ALTER TRIGGER

语法，也不能给触发器设权重或序号。若需调整顺序，只能删掉再重建——但要注意依赖关系：

DROP TRIGGER IF EXISTS
后必须立刻用新顺序
CREATE TRIGGER
，否则中间窗口可能被业务写入绕过逻辑 重建前应确认该触发器未被其他存储过程或应用逻辑隐式依赖（例如依赖其生成的临时状态） 在主从复制环境中，
DROP
+
CREATE
可能导致从库触发器缺失或顺序错乱，建议在维护窗口停写并校验

BEFORE 触发器中修改 NEW 值会影响后续触发器和主语句

只有

BEFORE INSERT

和

BEFORE UPDATE

允许赋值给

NEW.column_name

，这个修改会透传给后续所有同类型触发器，最终也作用于实际插入/更新的数据。而

AFTER

触发器读到的

NEW

已是最终值，不能修改。

CREATE TRIGGER tr_before_insert_user
  BEFORE INSERT ON users
  FOR EACH ROW
BEGIN
  SET NEW.created_at = NOW();
  SET NEW.status = IF(NEW.status IS NULL, 'active', NEW.status);
END;

如果还有另一个

BEFORE INSERT

触发器在它之后创建，它看到的

NEW.created_at

就已是

NOW()

的值，而非原始

NULL

。

嵌套触发器与性能风险需主动规避

MySQL 默认允许触发器内执行 DML 并再次激活其他触发器（即嵌套），最大深度由系统变量

max_sp_recursion_depth

控制（默认 0，表示不限制）。这容易引发意料外的连锁反应：

一个
UPDATE
触发器里更新了另一张表，恰好那张表也有
AFTER UPDATE
触发器，就构成嵌套递归无终止条件时可能快速耗尽栈空间，报错
ERROR 1456 (HY000): Recursive limit 0 (as set by the max_sp_recursion_depth variable)
嵌套层级越深，事务锁持有时间越长，死锁概率上升

生产环境建议显式设限：