触发器跨表校验必须用单值子查询+exists+signal，禁用join和select *；mysql需防1442错误与锁升级，postgresql须声明变量避免missing from-clause entry，且结尾必写return new/old。
触发器能做跨表校验，但不能无脑 JOIN；真正安全的做法是用单值子查询 + EXISTS + SIGNAL，且必须避开 MySQL 的 ERROR 1442 和 PostgreSQL 的 missing FROM-clause entry 这两类硬坑。
MySQL 中跨表校验为什么不能写 SELECT ... FROM other_table JOIN ...
在 BEFORE INSERT 触发器里执行带 JOIN 的复杂查询，会触发行锁升级，高并发下极易卡死或死锁。更关键的是，MySQL 默认隔离级别下，这类 SELECT 会加读锁，若关联字段恰好被其他事务更新中，就直接阻塞。
- 只查必要字段，用覆盖索引（比如
SELECT 1 FROM users WHERE id = NEW.user_id AND is_active = 1） - 禁止
SELECT *或无索引的WHERE条件 - 别在触发器里调用存储过程——函数内若含查询，同样触发
ERROR 1442 - 冗余字段比实时 JOIN 更稳：比如把
user_status冗余到订单表，校验时直接比NEW.user_status != 'blocked'
PostgreSQL 触发器函数里为什么报 missing FROM-clause entry for table xxx
这是语法限制：PostgreSQL 不允许在子查询中直接引用 NEW 或 OLD 当作表名，比如 SELECT id FROM NEW 是非法的，哪怕只是想取个字段值。
- 必须先声明变量：
DECLARE blocked_user BOOLEAN; - 再用
SELECT is_blocked INTO blocked_user FROM users WHERE id = NEW.user_id; - 最后用
IF blocked_user THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'user blocked'; END IF; - 结尾必须写
RETURN NEW;（INSERT/UPDATE）或RETURN OLD;（DELETE），漏写会导致写入静默失败
SQL Server 的 AFTER 触发器为啥拦不住插入
AFTER INSERT 执行时数据已落盘，此时抛异常（RAISERROR）只能回滚事务，但调用方未必捕获——用户看到“成功”，后台却在日志里打滚。
- 真正能拦截的只有
INSTEAD OF INSERT，但它不支持普通表，只支持视图 - 实用解法：建一个视图代理基表，把校验逻辑放在视图的
INSTEAD OF触发器里，让应用写视图而非表 - 或改用存储过程封装
INSERT + 校验查询，用TRY...CATCH统一处理 - 若必须用触发器，可用
CONTEXT_INFO让应用传标记，避免校验逻辑被循环触发
多对多中间表校验最容易踩的 1442 错误
在 student_course 表的触发器里，任何对该表的写操作（包括 INSERT、UPDATE、SELECT ... FOR UPDATE）都会立刻触发 ERROR 1442，这是 MySQL 硬性限制，不是写法问题。
- 允许的操作仅限单值子查询：
(SELECT 1 FROM student_course WHERE student_id = NEW.student_id AND course_id = NEW.course_id) - 防重逻辑必须压进
IF EXISTS (SELECT ...)，不能拆成SELECT COUNT(*) INTO @cnt再判断 - 用
EXISTS比=更安全：它不依赖变量，也天然规避NULL导致的误判 - 基础约束（如联合主键、外键）应优先由 DDL 实现，触发器只补复杂规则，比如“同一学生每学期最多选 5 门课”
跨表校验真正的难点不在语法，而在于锁行为和事务可见性——同一个 SELECT 在不同隔离级别下可能返回不同结果，尤其当关联表正在被并发更新时。这没法靠写对语句解决，得结合业务场景权衡：是接受短暂不一致，还是宁可慢一点也要强一致。
