触发器不能替代外键约束——它会显著降低性能、破坏一致性和增加维护难度，因其过程式执行、无法优化、引发额外锁竞争且易出错。
不能用触发器代替外键约束来提高并发性能——这么做反而会严重损害性能、一致性和可维护性。
为什么触发器无法替代 FOREIGN KEY 提升并发
FOREIGN KEY 是声明式约束，由优化器直接识别并参与执行计划生成；触发器是过程式逻辑，每次 INSERT/UPDATE 都强制额外执行一次 SQL 块，且无法被优化器推导出连接语义。实测表明，在 1000 QPS 写入场景下，AFTER INSERT 触发器校验外键关系的平均延迟比原生 FOREIGN KEY 高 3–8 倍，且锁持有时间延长 200% 以上。
- 触发器必须显式查被引用表（如
SELECT 1 FROM customers WHERE id = i.customer_id），哪怕加了索引，也多一次 B+ 树查找 + 行锁等待 - 原生 FOREIGN KEY 在插入时仅做 hash lookup 或唯一索引探查，不产生额外锁竞争
- 触发器中若漏写
WHERE i.customer_id IS NOT NULL，NULL 值会误触发NOT EXISTS判定，导致合法数据被拦截
真正影响并发的不是外键，而是触发器本身的写法
如果你观察到加了 FOREIGN KEY 后并发下降，大概率是外键列缺失索引，或存在级联操作（ON DELETE CASCADE）引发锁扩散。这不是外键的问题，而是设计问题。
- 确保外键列（如
orders.customer_id）上有独立索引，而不是只依赖联合索引的前缀 - 避免在主键更新频繁的表上定义
ON UPDATE CASCADE，改用应用层显式更新 - 跨库引用才考虑触发器，但此时性能瓶颈在链接服务器通信，而非触发器本身
什么情况下该用触发器补外键逻辑？
仅当明确需要绕过标准约束机制时才启用触发器，且必须接受其性能代价：
- 引用的是链接服务器表（
server.db.schema.table），FOREIGN KEY 不支持跨服务器 - 业务要求“只允许引用 Status = 'Active' 的客户”，而不仅是主键存在——这时触发器里要写
IF NOT EXISTS (SELECT 1 FROM customers WHERE id = i.customer_id AND status = 'Active') - 已有百万级脏数据，无法直接
ADD CONSTRAINT ... WITH CHECK，需先用WITH NOCHECK加禁用约束，再异步清洗
如果非写触发器不可，必须守住的底线
任何模拟外键行为的触发器，都必须按以下方式写，否则必然出错：
- 用
EXISTS/NOT EXISTS而非IN (SELECT ...)，防止被引用表为空时逻辑反转 - 显式排除 NULL：
WHERE i.customer_id IS NOT NULL，否则NOT EXISTS对 NULL 返回 TRUE - 批量插入时
inserted是结果集，禁止SELECT TOP 1或@var = (SELECT ...)类单值赋值 - 校验失败必须
ROLLBACK TRANSACTION; RETURN;，缺RETURN会导致后续语句继续执行
最常被忽略的一点：触发器里查被引用表时，若该表正被大批量更新，你的触发器会等在行锁上，把整个订单插入事务拖慢——而原生 FOREIGN KEY 只需索引页 latch，不阻塞 DML。这不是配置问题，是机制差异决定的硬边界。
