sql server 不支持跨数据库触发器实现参照完整性，因其 dml 触发器作用域限于单库，inserted/deleted 表不可跨库访问，且缺乏分布式事务保障，易致数据不一致；推荐用存储过程封装校验与写入，或应用层校验+最终一致性补偿。
不能直接在跨数据库场景下用标准 AFTER 或 INSTEAD OF 触发器实现参照完整性约束。 SQL Server 的 DML 触发器（INSERT/UPDATE/DELETE）作用域严格限定在**同一数据库内的表**上，不支持跨库引用 deleted 或 inserted 临时表，也不能在触发器主体中安全地对另一数据库的表执行写操作并参与事务原子性保障。
为什么跨库触发器在 SQL Server 中不可靠
SQL Server 不允许在触发器中显式开启跨数据库事务（如 BEGIN DISTRIBUTED TRANSACTION），而跨库写入又必须依赖分布式事务才能保证 ACID。即使你硬编码 UPDATE otherdb.dbo.table SET ...，也会遇到：
-
inserted和deleted表无法被跨库查询（它们只存在于当前会话的当前数据库上下文中） - 若目标库不可达、权限不足或语句失败，主库操作已提交，无法回滚，破坏数据一致性
- SQL Server 2017 默认禁用
Ad Hoc Distributed Queries，启用后仍不解决事务隔离问题 - 触发器嵌套层级受限（默认最多 32 层），跨库调用极易触达上限
替代方案：用视图 + INSTEAD OF 触发器模拟“逻辑跨库约束”
适用于只读或低频写入场景，本质是把跨库校验逻辑前置到应用层或中间层，再通过可控方式落地。例如：要确保 db1.dbo.orders 中的 customer_id 必须存在于 db2.dbo.customers 中：
- 在
db1中创建一个带检查逻辑的视图：CREATE VIEW dbo.v_orders_with_check AS SELECT o.*, c.name FROM db1.dbo.orders o LEFT JOIN db2.dbo.customers c ON o.customer_id = c.id - 在该视图上建
INSTEAD OF INSERT触发器，在触发器内手动查db2.dbo.customers并RAISERROR拒绝非法值 - 注意：此触发器中不能用
inserted直接 JOIN 跨库表（会报错），需先SELECT INTO #tmp FROM inserted，再用#tmp去查db2 - 所有写入必须走该视图，不能直写基表 —— 否则约束失效
更稳妥的做法：用存储过程封装跨库校验与写入
绕过触发器机制，把完整性逻辑收口到可测试、可审计的显式过程里：
- 定义存储过程
usp_insert_order_with_customer_check，参数含@customer_id - 过程内第一步：
IF NOT EXISTS (SELECT 1 FROM db2.dbo.customers WHERE id = @customer_id) BEGIN RAISERROR('Customer not found', 16, 1); RETURN; END - 第二步：在
db1中插入订单，并用TRY...CATCH包裹整个流程 - 调用方必须只调用该存储过程，禁用对
orders表的直接INSERT - 配合
DENY INSERT ON db1.dbo.orders TO [app_user]强制走过程
真正棘手的地方不是语法能不能写出来，而是事务边界和错误传播——跨库操作一旦出错，你没法让两个库同时回滚。所以关键不是“怎么写触发器”，而是“谁来承担校验责任、失败时谁来兜底”。多数生产系统最终都退回到应用层校验 + 最终一致性补偿，而不是强依赖数据库层的跨库触发器。
