触发器能补外键约束的盲区但不能替代它；适用于跨库校验、动态条件判断、主动防御误删及外键被禁用的兜底场景。
直接结论：触发器能补外键约束的盲区，但不能替代它；在跨库、复杂逻辑或需自定义报错时才值得用。
为什么外键约束不够用？
SQL 标准的 FOREIGN KEY 约束在多数场景下足够可靠，但它有硬性限制：
- 无法跨数据库或跨服务器校验（比如订单库的
customer_id指向客户主数据服务的远程表） - 不支持动态条件判断（例如“仅当订单状态为 draft 时才允许删除客户”）
- 级联操作（
ON DELETE CASCADE）一旦启用，删主记录会自动连带删子记录，风险不可逆 - 某些旧系统或迁移中表可能已禁用外键（
ALTER TABLE ... NOCHECK CONSTRAINT），此时只能靠触发器兜底
INSERT/UPDATE 触发器如何拦截非法外键值
核心思路是：在插入或更新子表前，查主表是否存在对应主键值；不存在就 ROLLBACK 并抛出自定义错误。
以订单表 Orders 引用客户表 Customers 为例：
CREATE TRIGGER tr_orders_customer_check
ON Orders
AFTER INSERT, UPDATE
AS
IF EXISTS (
SELECT 1 FROM inserted i
LEFT JOIN Customers c ON i.CustomerID = c.CustomerID
WHERE c.CustomerID IS NULL
)
BEGIN
RAISERROR('CustomerID %d does not exist in Customers table', 16, 1,
(SELECT TOP 1 CustomerID FROM inserted WHERE CustomerID NOT IN (SELECT CustomerID FROM Customers)))
ROLLBACK TRANSACTION
END注意点：
- 必须用
AFTER触发器，不能用INSTEAD OF——否则你得自己重写 INSERT/UPDATE 逻辑，容易漏字段 - 要同时检查
inserted表里所有行，不能只取TOP 1就退出，否则批量插入时部分非法值会被放过 - 错误信息里避免拼接敏感字段（如客户姓名），防止日志泄露；用 ID 更安全
DELETE 触发器如何阻止误删主记录
比起被动校验外键，更常见的是主动防御：删客户前，先确认有没有未结订单。这类逻辑外键做不到，必须触发器。
CREATE TRIGGER tr_customers_prevent_delete
ON Customers
INSTEAD OF DELETE
AS
IF EXISTS (
SELECT 1 FROM deleted d
INNER JOIN Orders o ON d.CustomerID = o.CustomerID
WHERE o.Status != 'cancelled'
)
BEGIN
RAISERROR('Cannot delete customer with active orders', 16, 1)
ROLLBACK TRANSACTION
RETURN
END
-- 真正执行删除
DELETE FROM Customers WHERE CustomerID IN (SELECT CustomerID FROM deleted)关键细节：
- 这里必须用
INSTEAD OF，因为你要拦截并控制整个删除流程；AFTER触发器删完才触发，来不及救 - 检查条件要明确业务语义（比如只拦
Status != 'cancelled'，而不是所有订单） - 最后那句
DELETE是必需的——INSTEAD OF不会自动执行原操作 - 别忘了处理批量删除：
deleted表可能含多行，WHERE 子句要支持集合操作
生产环境踩坑最频繁的三个点
触发器不是加了就高枕无忧，这些地方一疏忽就会引发线上事故：
- 事务嵌套失控：
TRIGGER和调用它的语句共享同一事务，若触发器里再显式BEGIN TRAN，极易导致死锁或ROLLBACK范围超出预期 - 性能雪崩：触发器里做全表扫描（比如没给
Customers(CustomerID)加索引）、或调用远程链接服务器（OPENQUERY），会让单条 INSERT 变成秒级延迟 - 忽略
TRUNCATE TABLE：TRUNCATE不走触发器，但会清空子表数据，瞬间制造大量孤立记录——必须靠权限管控 + 监控告警补位
真正难的从来不是写触发器，而是确认它在哪种并发路径下会失效、在哪种数据分布下会拖慢整个系统。上线前务必用真实数据量压测，并在日志里埋点记录触发器执行耗时。
