不能直接用触发器替代外键约束，因为外键是声明式、优化器感知的原生机制，而触发器是过程式、性能开销大、易出错的补充手段；仅在跨库引用、动态校验、日志告警或处理脏数据时才应使用触发器补足。

FOREIGN KEY 约束本身是 SQL Server 原生支持的强制完整性机制，不推荐用触发器替代它来“模拟”外键行为——除非你明确需要绕过约束检查（比如批量导入脏数据后统一校验），或必须跨数据库、跨服务器引用（此时 FOREIGN KEY 无法使用）。

触发器不是外键的“升级版”，而是兜底/补充手段。强行用 INSTEAD OF 或 AFTER INSERT/UPDATE 触发器重写外键逻辑，反而会引入性能瓶颈、死锁风险和维护盲区。

为什么不能直接用触发器“替代”外键约束？

• FOREIGN KEY 是声明式约束，由查询优化器识别并参与执行计划生成；触发器是过程式逻辑，每次 DML 都要额外调用，且无法被优化器推导出连接语义
• 触发器不自动阻止级联操作（如 ON DELETE CASCADE），需手动实现，极易遗漏 UPDATE 场景或 NULL 处理
• 多个触发器叠加时，执行顺序不可控（sp_settriggerorder 仅限 FIRST/LAST，中间顺序无保证）
• inserted 和 deleted 表在批量操作中可能含多行，但新手常按单行逻辑写（如 SELECT TOP 1 ...），导致部分数据逃逸校验

什么情况下才该用触发器补外键？

• 被引用表不在同一数据库（例如引用链接服务器表），FOREIGN KEY 不支持跨库（除同实例下 DB 名前缀外），更不支持跨服务器
• 需要动态判断引用有效性（例如：只允许引用 Status = 'Active' 的客户，而不仅是主键存在）
• 需要记录违规操作日志或发送告警，而非单纯报错回滚
• 遗留系统中已有大量脏数据，无法直接加 FOREIGN KEY（此时应先用 WITH NOCHECK 添加禁用验证的约束，再逐步清洗）

如果真要写触发器模拟外键，关键写法要点

• 必须处理多行插入：INSERT 语句可能一次插入 N 行，inserted 是结果集，不能用 IF EXISTS (SELECT 1 FROM inserted WHERE ...) 这类单值假设
• 显式回滚整个事务：ROLLBACK TRANSACTION 后必须跟 RETURN，否则后续语句仍会执行
• 检查 NULL 值：外键列允许 NULL，触发器里要排除 IS NULL 情况，否则 NOT EXISTS 判定会误报
• 示例（安全写法）：

  CREATE TRIGGER trg_ValidateCustomerID ON Orders
  AFTER INSERT, UPDATE
  AS
  BEGIN
    IF UPDATE(CustomerID)
    BEGIN
        IF EXISTS (
            SELECT 1 FROM inserted i
            WHERE i.CustomerID IS NOT NULL
              AND NOT EXISTS (
                  SELECT 1 FROM Customers c WHERE c.CustomerID = i.CustomerID
              )
        )
        BEGIN
            RAISERROR('CustomerID does not exist in Customers table', 16, 1);
            ROLLBACK TRANSACTION;
            RETURN;
        END
    END
  END;

最容易被忽略的细节

• UPDATE 触发器必须同时检查 inserted.CustomerID 和 deleted.CustomerID —— 如果只是改了其他字段，CustomerID 没变，不该触发校验；但如果 CustomerID 从有效值改成无效值，就必须拦截
• WITH NOCHECK 添加的 FOREIGN KEY 约束不会激活触发器，但也不会阻止数据不一致；触发器是独立运行的，二者不联动
• 触发器里不能调用修改同一表的存储过程（容易死锁），也不能依赖未提交事务中的其他会话数据