触发器无法检查外键合法性，因外键不匹配在解析与约束校验阶段即被数据库硬拦截并报错，触发器根本不会执行；它仅对已通过外键检查的数据生效，仅适用于状态、额度等外键无法覆盖的业务规则校验。
触发器不能检查外键关联是否合法——外键不匹配根本到不了触发器执行阶段。
为什么 BEFORE INSERT 触发器查不到外键错误
当你执行 INSERT INTO orders (user_id) VALUES (999)，而 users 表里没有 id = 999 的记录时，MySQL 或 PostgreSQL 在语法解析和约束校验阶段就直接报错：Cannot add or update a child row: a foreign key constraint fails。这个错误发生在触发器调用之前，BEFORE INSERT 根本不会运行。
换句话说：触发器看到的 NEW.user_id 只是一个整数值，它不负责、也无法验证这个值是否真实存在于被引用表中——那是 FOREIGN KEY 约束的职责。
- 外键约束在 DDL 解析层硬拦截，是数据库引擎内建的安全机制
- 触发器只对“已通过所有约束检查”的数据生效
- 用触发器模拟外键检查，等于拆掉安全带再装个喇叭提醒
什么情况下才该用触发器做关联校验
仅当业务规则超出标准外键能力时才需要触发器，比如：
- 要求
orders.user_id必须对应一个status = 'active'的用户（外键只管存在，不管状态） - 插入订单前要检查该用户当前
credit_limit >= NEW.amount（需查另一字段，且涉及计算） - 子表插入前验证主表某字段不是
'archived'（如projects.status != 'archived'）
这类逻辑必须用 BEFORE INSERT/UPDATE，并配合 SIGNAL SQLSTATE '45000' 中断流程，否则校验形同虚设。
MySQL 触发器里怎么安全查关联表
直接 SELECT ... FROM users WHERE id = NEW.user_id 看似简单，但高并发下可能因隔离级别读到过期快照，且没索引会全表扫描。
- 务必在被查字段上建覆盖索引，例如
CREATE INDEX idx_users_id_status ON users(id, status) - 避免
SELECT *，只查必要字段（如SELECT status INTO @u_status FROM users WHERE id = NEW.user_id） - 禁止在触发器里
SELECT FROM NEW或对当前表做写操作，MySQL 会报Can't update table 'orders' in stored function/trigger - 校验失败统一用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'user inactive'，别用SELECT模拟异常
PostgreSQL 触发器函数常见陷阱
PostgreSQL 对 NEW 行的引用更严格，不能像 MySQL 那样直接在子查询里用字段名。
- 错误写法：
SELECT amount FROM NEW WHERE user_id IN (SELECT user_id FROM users WHERE is_blocked = true) - 正确做法：先
DECLARE blocked_user BOOLEAN，再SELECT is_blocked INTO blocked_user FROM users WHERE id = NEW.user_id - 必须以
RETURN NEW（INSERT/UPDATE）或RETURN OLD（DELETE）结尾，漏写会导致数据静默丢失 - 子查询里不能出现
missing FROM-clause entry for table "new"这类报错，本质是语法不允许把NEW当作表名直接引用
真正容易被忽略的点是：触发器校验永远晚于外键约束，也永远慢于索引查找。如果外键没加，补上 FOREIGN KEY 约束才是第一优先级；触发器只该用于“外键管不了”的那部分业务逻辑，而且得配好索引、控制好锁粒度。
