MySQL 8.0.19+ 查触发器执行顺序需结合 SHOW CREATE TRIGGER 看 FOLLOWS/PRECEDES 定义，INFORMATION_SCHEMA.TRIGGERS 的 CREATED 仅作参考；PostgreSQL 依赖创建时间且不可动态调整；SQL Server 用 sp_settriggerorder 设 First/Last，但仅对 AFTER 触发器有效且有严格限制。
MySQL 8.0.19+ 怎么查触发器当前执行顺序
MySQL 不提供直接显示“执行顺序编号”的视图，INFORMATION_SCHEMA.TRIGGERS 表里没有排序字段，但你可以通过 CREATED 时间和 EVENT_MANIPULATION + ACTION_TIMING 组合推断逻辑顺序——前提是没用 FOLLOWS/PRECEDES 显式覆盖。
真正可靠的查法是看定义语句本身：
-
SHOW CREATE TRIGGER tr_validate;—— 查单个触发器是否带FOLLOWS tr_log或PRECEDES -
SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING, ACTION_STATEMENT FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'orders' ORDER BY CREATED;—— 按创建时间排序，仅作参考（若用了FOLLOWS，这个顺序就失效）
注意：FOLLOWS 是相对关系，不是绝对序号。比如 tr_a FOLLOWS tr_b，tr_c FOLLOWS tr_a，不代表 tr_c 一定在 tr_b 之后——只要 tr_b 存在，tr_a 就在它后；tr_c 只保证在 tr_a 后，不自动链式传递。
PostgreSQL 触发器顺序能改吗
不能动态调整。PostgreSQL 完全不支持 ALTER TRIGGER ... DEPENDS ON 控制执行顺序——那个语法只影响 DROP 时的依赖校验，对运行时触发毫无作用。
同类触发器（如两个 BEFORE INSERT FOR EACH ROW）严格按 CREATE TRIGGER 的时间先后执行：先建的先跑，后建的后跑。
- 想重排？唯一办法是
DROP TRIGGER tr_later; CREATE TRIGGER tr_later ...—— 把它重建一次，就会排到最后 -
pg_trigger系统表里只有tgname、tgenabled等字段，没有tgorder或权重列 - 别试图用
ALTER TABLE ... ALTER TRIGGER ... DEPENDS ON去“设优先级”，它不会改变任何执行行为
SQL Server 的 sp_settriggerorder 为什么总失败
报错 Msg 20101 几乎都因为违反了三条硬规则：
- 必须先
CREATE所有触发器，再调用sp_settriggerorder—— 不能边建边设 - 每个事件（
INSERT/UPDATE/DELETE）最多只能设一个First和一个Last；重复设同一个触发器为First就会炸 -
INSTEAD OF触发器不支持设顺序，sp_settriggerorder只对AFTER有效
另外注意：First 和 Last 之间那些触发器，执行顺序是未定义的——数据库不保证它们之间的相对次序，只保证 First 最先、Last 最后。
跨数据库统一控制触发顺序的务实做法
别指望靠各库的“顺序机制”达成一致。MySQL 的 FOLLOWS、SQL Server 的 First/Last、PostgreSQL 的创建时序，三者语义不同、能力不同、错误表现也不同。
真正稳定的做法是放弃多触发器拆分，改用单触发器 + 显式逻辑编排：
- 把校验、默认值填充、日志记录等原本分散在多个触发器里的动作，合并进一个
BEFORE INSERT里，用IF或CASE分支控制流程 - 如果逻辑太重，抽成存储过程（如
sp_validate_user()、sp_log_insert()），在触发器里按需调用 - 避免在触发器里调外部 HTTP 请求或长事务——这类操作会让“顺序”失去意义，实际执行被锁等待、超时、网络抖动掩盖
最易被忽略的一点：触发器间的数据可见性依赖执行顺序，而顺序又受数据库实现绑架。与其花精力绕开限制，不如让逻辑本身不依赖顺序——比如所有默认值都在同一触发器里一次性赋值，而不是靠前一个触发器设 NEW.created_at，后一个触发器读它。
