SQL Server外键不支持跨库、跨schema及业务逻辑验证，须用触发器实现；触发器需用inserted/deleted联查、加UPDATE判断、权限配置、锁提示及空值处理，并拆分复杂校验。
为什么不能只靠外键约束做跨表验证
SQL Server 的 FOREIGN KEY 约束本身不支持跨数据库、跨 schema、或基于表达式/业务逻辑的验证。比如你没法写一个外键去检查 “子表中 order_date 必须早于主表 contract_end_date”，也没法引用另一库里的 OtherDB.dbo.Customers.id。这时候外键直接报错或干脆不生效，不是你语法错了，是它压根不支持。
AFTER UPDATE 触发器里怎么安全比对主子表数据
用 inserted 和 deleted 虚拟表联查时，必须加 IF UPDATE(column_name) 判断，否则只要整行更新（哪怕只改了无关字段），触发器也会无谓执行全量校验，拖慢性能还可能误报。
- 主表
Contracts有id,end_date；子表Orders有contract_id,order_date - 触发器里要查：是否存在
o.order_date > c.end_date的记录 - 必须用
INNER JOIN inserted i ON i.contract_id = c.id，而不是直接FROM inserted—— 否则会漏掉未被更新但已违规的历史数据 - 发现违规就用
RAISERROR+ROLLBACK，别只打印警告
跨数据库验证必须用三部分路径+显式权限
如果真要查 OtherDB.dbo.Customers，得在触发器里写完整四段式名：OtherDB.dbo.Customers，且当前执行用户必须对 OtherDB 有 SELECT 权限——外键做不到这点，但触发器能，前提是权限配对。
- 不能省略
dbo，否则可能命中同名 schema 导致查错表 - 跨库查询会增加锁竞争和网络延迟，建议加
NOLOCK（仅当业务允许脏读时） - 若目标库是只读副本，
SELECT会失败，得提前用DB_ID('OtherDB')做存在性判断再分支处理
容易忽略的并发与空值陷阱
触发器运行在事务上下文中，但 inserted/deleted 只反映本次语句影响的行。如果两个事务同时更新同一主表行，又都触发校验逻辑，可能互相看不到对方还没提交的变更，导致校验通过但最终数据违规。
- 对关键校验字段（如日期、状态码）加
UPDLOCK, HOLDLOCK提示锁，避免幻读 -
NULL值参与比较一律返回UNKNOWN，所以WHERE order_date > end_date不会匹配NULL，但你要校验“不能为空”就得单独写IS NULL分支 - 触发器开头必须加
SET NOCOUNT ON，否则客户端收到多结果集会中断后续逻辑（尤其 ORM 框架）
实际中最难缠的不是语法，是校验逻辑嵌套多层后，你根本不确定哪一次 UPDATE 是最后一个真正落地的——所以别指望单个触发器包打天下，复杂规则得拆成多个轻量触发器，各自专注一件事。
