MySQL无法设置触发器优先级，不支持FOLLOWS、PRECEDES或TRIGGER_ORDER语法；同类型触发器执行顺序仅由创建时间升序决定，但官方不保证且不建议依赖，唯一可靠方案是合并为单个触发器并显式控制逻辑顺序。
MySQL 里根本没法设触发器优先级
MySQL 不支持 FOLLOWS、PRECEDES 或任何类似 TRIGGER_ORDER 的语法。哪怕你看到网上说“MySQL 8.0+ 支持”，那也是错的——官方文档和实际行为都确认：同类型触发器（比如两个 BEFORE INSERT）执行顺序未定义，仅依赖创建时间，但不保证、不承诺、不建议依赖。
常见错误现象：ERROR 1235 (42000) 这类报错早已移除，现在能建多个同类型触发器，不代表你能控制谁先谁后。上线后逻辑错乱往往就出在这儿。
- 如果你在
tr_validate里校验NEW.email，又在tr_set_defaults里给它赋默认值，谁先执行？不确定 -
SHOW TRIGGERS输出的顺序只是查询结果排序，不是执行顺序承诺 - 主从复制中，从库重建触发器时时间戳不同，可能造成主从行为不一致
SQL Server 只能设 First 和 Last，中间顺序不管
sp_settriggerorder 看似能控顺序，其实只允许你指定一个 First 和一个 Last 触发器，其余全靠“未定义顺序”——也就是数据库自己决定，你没法干预。
典型踩坑点：Msg 20101 报错，通常是因为重复设置 First，或者试图给 INSTEAD OF 触发器设顺序（它不支持）。
- 必须先
CREATE所有触发器，再调用sp_settriggerorder -
@stmttype必须严格匹配触发器定义的语句类型（比如INSERT），不能混用 - 同一张表上，每个事件类型（
INSERT/UPDATE/DELETE）各自独立管理顺序，不能跨事件联动
PostgreSQL 也没有真正的优先级字段
PostgreSQL 的 DEPENDS ON 只影响对象删除时的依赖检查，对触发器执行顺序完全无效。多个 BEFORE INSERT 触发器依然按创建顺序执行，且无法用 ALTER 修改。
想重排？只能 DROP 再 CREATE，没有中间态。pg_trigger 系统表里没有权重列，只有 tgname 和 tgenabled。
- 不要指望用函数名、注释或命名规则来“暗示”顺序——没用
- 约束触发器（
CONSTRAINT TRIGGER）虽然延迟到事务末尾执行，但仍是同类型内按创建顺序，不提供优先级声明 - 跨表操作（比如
AFTER INSERT ON t1更新t2）要注意事务一致性，失败会回滚整个事务
唯一真正可控的做法：合并进一个触发器
别拆。把审计、校验、状态更新、日志写入等所有逻辑，全部塞进一个 BEFORE INSERT 或 AFTER UPDATE 触发器里，用 IF/CASE 分段控制流程。
这不是妥协，是唯一能规避不确定性的方式。尤其当多个逻辑存在数据依赖（比如 A 改了 NEW.status，B 要读它）时，拆成多个触发器等于主动放弃控制权。
- 用注释分隔逻辑块：
-- [VALIDATE] 邮箱格式、-- [ENRICH] 补充 created_at - 复杂查询或外部调用，抽成独立存储过程，在触发器里显式调用，避免嵌套扩散
- 设
max_sp_recursion_depth = 1防止意外嵌套，否则锁等待和死锁风险陡增
触发器不是编排引擎。真需要强顺序，就该用应用层事务或存储过程封装，而不是靠数据库猜顺序。
