触发器查子表状态总查不到最新数据，是因为after触发器执行时事务未提交，子表变更尚未落盘，且存在“谁先改”的逻辑死锁；应统一用before触发器配合select...for update校验，并避免跨表循环依赖。

触发器里查子表状态时为什么总查不到最新数据？

因为 AFTER INSERT/UPDATE 触发器执行时，当前事务还没提交，但子表的变更可能尚未写入（尤其在 INSERT 场景下，子表记录还没插入）。更关键的是：如果你在父表 AFTER UPDATE 里去查子表，而子表的更新又依赖父表状态——就容易陷入“谁先改”的死锁逻辑。实际做法是统一用 BEFORE 触发器，在数据落盘前做校验：
- 父表 BEFORE UPDATE 中，用 SELECT ... FOR UPDATE 锁住关联子表记录（防止并发修改）
- 再查子表当前 status 是否满足业务规则（比如：父表设为「已归档」时，所有子表必须是「已完成」或「已取消」）
- 不满足就抛出异常：RAISE EXCEPTION '子表状态不一致，禁止更新父表状态';

子表触发器怎么避免重复校验父表？

子表 BEFORE INSERT/UPDATE 里如果每次都查父表状态，会引发两个问题：一是父表可能正被其他事务修改，导致幻读；二是多个子表同时更新时，反复查父表效率低。解决方案是只校验「影响父表状态的字段」：
- 只有当子表的 status 字段被显式修改时，才去查父表当前值
- 用 OLD.status IS DISTINCT FROM NEW.status 判断是否真变了
- 查父表时加 SELECT ... FOR SHARE（非阻塞读），而非 FOR UPDATE（避免和父表触发器争锁）
- 若父表状态为「草稿」，但子表要设为「已发货」，直接拒绝：RAISE EXCEPTION '父表为草稿态，子表不可进入发货流程';

MySQL 和 PostgreSQL 在触发器级联校验上有啥关键差异？

MySQL 的触发器不能在同一个语句中修改本表或关联表（会报 Can't update table in stored function/trigger），所以只能做校验，不能自动修正；PostgreSQL 允许在触发器里执行任意 SQL，但要注意：
- MySQL 必须把校验逻辑全写在 BEFORE 触发器里，且不能调用存储过程修改数据
- PostgreSQL 可以在 BEFORE 触发器中用 NEW.parent_status := 'pending' 主动重置字段，但要小心循环触发（比如子表改了父表字段，又触发父表触发器）
- 两者都禁止在触发器里开启新事务，所以 COMMIT / ROLLBACK 会直接报错
- 跨表校验时，PostgreSQL 支持窗口函数和 CTE，MySQL 8.0+ 才支持，老版本得拆成多条 SELECT

为什么用触发器做双向校验比应用层更难维护？

因为校验逻辑散落在数据库多个触发器里，没有统一入口，排查时得连着看父表、子表、甚至中间状态表的全部触发器代码。最常被忽略的一点是：触发器不参与应用层的事务日志审计，一旦因校验失败回滚，业务系统只看到一个模糊的 SQL 错误，不知道具体卡在哪条规则上。建议：
- 所有 RAISE EXCEPTION 或 SIGNAL SQLSTATE 都带明确前缀，比如 'CHK_PARENT_STATUS_MISMATCH'
- 在触发器开头用 IF TG_OP = 'UPDATE' AND NOT (OLD.status IS DISTINCT FROM NEW.status) THEN RETURN NEW; END IF; 快速跳过无意义更新
- 避免在触发器里调用外部函数或查询视图（尤其是含聚合的视图），否则性能抖动不可控