触发器执行顺序不可控，多表AFTER触发器互相修改易出错；应避免直接更新关联表，改用异步、单触发器整合或约束延迟；SQL Server禁嵌套INSTEAD OF；Oracle行触发器禁用FOR UPDATE；跨库迁移需统一函数封装并人工核验条件。
触发器执行顺序不可控，AFTER 触发器里改 JOIN 相关表会出错
MySQL 和 PostgreSQL 都不保证多表 AFTER INSERT 触发器的执行顺序，尤其当多个触发器监听同一事件、又互相修改对方依赖的表时，极易出现“表被其他触发器正在更新”的错误，比如 MySQL 的 ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already being used by statement which invoked this stored function/trigger。
实操建议：
- 避免在
AFTER触发器中直接UPDATE或INSERT其他被级联关联的表；改用异步方式（如写入日志表 + 定时任务）或应用层统一协调 - 若必须同步处理，把多表逻辑收拢到单个触发器内，用
NEW和OLD显式拼装完整上下文，而不是靠多个触发器接力 - PostgreSQL 可用
CONSTRAINT TRIGGER配合DEFERRABLE INITIALLY DEFERRED把触发时机推迟到事务末尾，避开中间态冲突
SQL Server 的 INSTEAD OF 触发器不能嵌套调用自身
在级联场景下，有人试图用 INSTEAD OF INSERT 拦截主表操作，再手动 INSERT 子表——但若子表也有同名 INSTEAD OF 触发器，SQL Server 默认禁止递归调用，会直接报错 Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)，哪怕实际只嵌了两层。
实操建议：
- 检查
sp_configure 'nested triggers'是否为 1（默认是），但即使开启，也不推荐依赖嵌套；更稳妥的是关闭子表的INSTEAD OF，改用AFTER+ 显式校验 - 在主表触发器里，用
IF NOT EXISTS (SELECT 1 FROM inserted i JOIN sys.triggers t ON ...)这类轻量判断绕过重复拦截（需结合业务唯一键） - 对强一致性要求高的场景，干脆不用触发器，改用存储过程封装整个级联写入流程，由应用显式调用
Oracle 的 FOR EACH ROW 触发器读 SELECT FOR UPDATE 会死锁
当一个 FOR EACH ROW 触发器内部执行 SELECT ... FROM child_table WHERE parent_id = :NEW.id FOR UPDATE，而同时另一事务正更新该 child_table 记录，就会立刻陷入行锁等待。更麻烦的是，Oracle 触发器运行在父语句的事务上下文中，无法提交或回滚子查询锁，死锁检测可能延迟数秒才报 ORA-00060: deadlock detected while waiting for resource。
实操建议：
- 绝对不要在行级触发器里加
FOR UPDATE；改用SELECT ... AS OF TIMESTAMP或物化视图获取快照数据 - 如果必须校验子表状态，优先查
USER_CONSTRAINTS或外键约束定义，而非实时数据 - 把耗时或带锁逻辑移到
COMMIT后的DBMS_ALERT或调度作业中，触发器只做轻量标记（如设status = 'PENDING_CASCADE'）
跨数据库迁移时，TRIGGER 的激活条件语法不兼容
MySQL 用 BEFORE/AFTER INSERT/UPDATE/DELETE ON table_name，PostgreSQL 要写 EXECUTE FUNCTION func_name() ON INSERT OR UPDATE OR DELETE，而 SQL Server 的 ON table_name AFTER INSERT, UPDATE 不支持混合事件声明。一旦混用，建表就失败，且错误提示往往只说“syntax error near ‘OR’”，不指明是触发器部分。
实操建议：
- 所有触发器逻辑抽成独立函数（
CREATE FUNCTION cascade_update_child() RETURNS TRIGGER），再按目标库语法绑定事件，降低迁移成本 - 用
pg_dump --no-owner --no-privileges --schema-only导出 PostgreSQL 触发器定义时，务必人工核对WHEN (OLD.status IS DISTINCT FROM NEW.status)这类条件表达式是否被正确保留 - 测试阶段在 CI 中跑一个最小验证 SQL：插入主表后立刻
SELECT COUNT(*) FROM child_table，比单纯看 DDL 语法是否通过更能暴露执行逻辑差异
触发顺序管理的本质不是“怎么排先后”，而是“怎么让各环节不互相看见彼此正在写的中间状态”。越想靠触发器自动串起来，越容易掉进隐式事务和锁粒度的坑里。
