不能。postgresql中alter table ... alter trigger ... depends on仅影响删除依赖检查，不控制触发顺序；同类触发器按创建顺序执行，重排唯一方式是drop后重建。
PostgreSQL 中 CREATE TRIGGER 的执行顺序能靠 ALTER TABLE ... ALTER TRIGGER ... DEPENDS ON 控制吗？
不能。PostgreSQL 不支持触发器优先级或显式执行顺序配置。DEPENDS ON 只影响对象删除时的依赖检查，对触发器触发顺序完全无效。多个触发器在同一事件（如 BEFORE INSERT）上定义时，按创建顺序执行——先 CREATE 的先运行。
- 触发器顺序在创建后即固化，
DROP+CREATE是唯一重排方式 - 同类触发器（如两个
BEFORE INSERT FOR EACH ROW）之间无“优先级”字段可设 -
pg_trigger系统表中没有排序权重列，只有tgname和tgenabled
MySQL 8.0+ 的 TRIGGER_ORDER 参数真能指定先后？
能，但仅限于同一张表、同一事件、同一触发时机（如都为 BEFORE INSERT）下的两个触发器，且必须用 TRIGGER_ORDER = {FOLLOWS | PRECEDES} 显式声明。
- 必须成对设置：若 A
FOLLOWS B，则 B 必须存在且同类型；不能只设一个 - 不支持链式声明（A FOLLOWS B，B FOLLOWS C → A 不自动在 C 后）
- 错误示例：
ERROR 3858 (HY000): Trigger in the 'FOLLOWS' clause does not exist - 示例语句：
CREATE TRIGGER tr_log BEFORE INSERT ON orders FOR EACH ROW ...;<br>CREATE TRIGGER tr_validate BEFORE INSERT ON orders FOR EACH ROW FOLLOWS tr_log;
SQL Server 的 sp_settriggerorder 为什么总报错 Msg 20101？
因为该存储过程只接受 三个特定触发器名：一个 First、一个 Last、其余自动居中；且仅支持 INSERT/UPDATE/DELETE 各一套独立顺序，不跨事件混排。
- 必须先创建所有触发器，再调用
sp_settriggerorder设置 - 同一事件下最多只能设一个
First和一个Last，重复设置会报Msg 20101 - 不支持
INSTEAD OF触发器设顺序（只对AFTER有效） - 常见误操作：对已设过
First的触发器再次执行sp_settriggerorder @triggername = 't1', @order='First'
跨数据库统一保障顺序的务实做法是什么？
放弃依赖各数据库的“顺序机制”，改用单触发器 + 显式逻辑编排：
- 把原本拆成多个触发器的职责，合并进一个
BEFORE或AFTER触发器里，用IF/CASE分支控制执行流 - 若逻辑太重，把校验、日志、同步等动作抽成存储过程，在触发器内按需调用
- 避免在触发器里调用外部服务或长事务操作，否则顺序可控性会被锁等待、超时等掩盖
- 真正关键的顺序依赖（比如“先校验再写入”），应提到应用层做，触发器只做最终兜底
触发器顺序不是编程接口，而是数据库内部调度的副产品。越想靠它做业务编排，越容易掉进兼容性坑里。
