SQL Server 不支持跨数据库 FOREIGN KEY 约束，必须用 INSTEAD OF 触发器手动验证引用完整性；但触发器无法实现级联操作、性能较差、事务与权限复杂，属权衡后的妥协方案。
SQL Server 不允许跨数据库定义 FOREIGN KEY 约束，所以必须用触发器手动模拟引用完整性检查 —— 但要注意，这不是“替代方案”，而是权衡后的妥协方案。
为什么不能直接建跨库外键
SQL Server 的 FOREIGN KEY 语法明确限制：被引用的表必须与当前表位于同一数据库内。哪怕两个库在同一个实例、同一服务器上，REFERENCES other_db.dbo.table(col) 也会报错 Msg 1763 或 Msg 1776。这是引擎层硬性限制，不是权限或语法问题。
- 跨库引用无法参与查询优化器的 join 消除、外键推送等优化
- 系统视图
sys.foreign_keys和sys.foreign_key_columns完全不记录跨库关系 - 备份/还原、Always On 故障转移时，跨库依赖容易变成“隐式耦合”，出问题难定位
用 INSTEAD OF 触发器拦截 INSERT/UPDATE
核心思路是：在子表执行 INSERT 或 UPDATE 前，主动查父表（跨库）验证值是否存在。失败则 RAISERROR 并 ROLLBACK。
- 必须用
INSTEAD OF（不是AFTER），否则数据已写入再回滚，可能触发其他副作用（如日志、CDC） - 触发器里跨库查询要写全名：
SELECT 1 FROM other_db.dbo.parent_table WHERE id = @ref_id - 注意
NULL处理：外键列允许NULL时，WHERE条件需显式排除，避免误判 - 批量插入（
INSERT ... SELECT）时，触发器对每一行都生效，但性能比原生外键差一个数量级
CREATE TRIGGER tr_orders_customer_check
ON dbo.orders
INSTEAD OF INSERT
AS
BEGIN
IF EXISTS (
SELECT 1 FROM inserted i
LEFT JOIN other_db.dbo.customers c ON c.id = i.customer_id
WHERE i.customer_id IS NOT NULL AND c.id IS NULL
)
BEGIN
RAISERROR('customer_id not found in other_db.dbo.customers', 16, 1);
ROLLBACK;
RETURN;
END
INSERT INTO dbo.orders SELECT * FROM inserted;
END;DELETE/UPDATE 级联需额外处理
原生外键的 ON DELETE CASCADE 或 ON UPDATE CASCADE 在跨库场景下完全失效。触发器只能做“检查”，不能自动同步删改父库数据。
- 若业务要求级联删除，必须在应用层或存储过程中显式调用
DELETE FROM other_db.dbo.parent WHERE id = @id，再删子表 - 触发器里执行跨库
DELETE风险极高：事务跨越数据库，可能造成分布式事务（MS DTC），增加锁等待和失败概率 - 更稳妥的做法是：把父表关键字段冗余到子库（如
customer_name），用CHECK约束 + 定期校验任务补漏
最容易被忽略的坑：事务隔离与权限
触发器运行在调用语句的同一事务中，但跨库查询受各自数据库的隔离级别影响。比如子库 READ COMMITTED，父库 SNAPSHOT，可能读到不一致的中间状态。
- 确保父库账号对触发器中访问的表有
SELECT权限，且该权限不能依赖guest用户（默认禁用） - 避免在触发器里调用跨库函数或视图，它们可能隐式开启新事务或改变上下文
- 测试时一定要覆盖并发场景：两个会话同时插入相同
customer_id，一个成功一个失败，是否阻塞合理？
真正麻烦的从来不是写几行触发器，而是后续所有迁移脚本、备份策略、监控告警都得意识到：这里有一层手写的、不可见的、跨库的数据耦合。它不会出现在 sp_helpconstraint 里，也不会被 ORM 自动识别。
