外键约束是关系型数据库保证引用完整性的标准手段，但在实际项目中，出于分库分表、历史遗留架构或性能考虑，很多团队会放弃在表结构上直接声明外键，转而在逻辑层用触发器来实现类似的校验效果。触发器方案的好处是校验逻辑完全可控，可以随时修改规则，还能附加业务判断，比如只对特定状态的数据做引用校验。本文将从原理、写法、坑点三个层面，完整讲清楚如何用触发器替代系统外键约束。
为什么有时需要用触发器替代原生外键约束
原生外键约束由存储引擎层面实现，校验发生在语句执行阶段，效率高且绝对可靠。但在一些特定场景下它并不适用。第一种是分库分表环境，子表和父表可能不在同一个数据库实例上，数据库本身无法跨实例建立外键。第二种是一些互联网公司的DBA规范明确禁止使用外键，因为外键带来的锁开销在高并发写入场景下会成为瓶颈，尤其是父表频繁更新时，子表上的外键检查会放大锁竞争。第三种是遗留系统改造，表已经存在大量历史脏数据，直接加外键约束会失败，而清洗数据需要一个过渡期，这段时间可以用触发器做增量管控。
触发器方案的本质是把校验时机放在DML语句执行前后，通过显式查询父表来判断引用是否有效。相比应用层校验，触发器运行在数据库内部，无法被绕过，即使有人直接用命令行改数据也会被拦截，这是它最大的价值。当然它也有代价：每次写入都多一次或多次查询，且触发器逻辑对应用开发者是隐藏的，排查问题时容易被忽略，这些在后面的坑点部分会详细讨论。
在子表上编写INSERT和UPDATE触发器校验引用有效性
替代外键的第一步是在子表上拦截写入。以订单表（orders）引用用户表（users）为例，需要在订单表上创建BEFORE INSERT和BEFORE UPDATE两个触发器，检查user_id在父表中是否存在。先看MySQL的写法：
DELIMITER $$
CREATE TRIGGER trg_orders_bi
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
DECLARE parent_count INT;
SELECT COUNT(*) INTO parent_count FROM users WHERE id = NEW.user_id;
IF parent_count = 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '外键校验失败：user_id在users表中不存在';
END IF;
END$$
CREATE TRIGGER trg_orders_bu
BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
DECLARE parent_count INT;
-- 只有当user_id发生变化时才需要校验
IF NEW.user_id <> OLD.user_id THEN
SELECT COUNT(*) INTO parent_count FROM users WHERE id = NEW.user_id;
IF parent_count = 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '外键校验失败：user_id在users表中不存在';
END IF;
END IF;
END$$
DELIMITER ;
这里有几个细节值得注意。第一，SIGNAL SQLSTATE '45000'是MySQL中主动抛出错误的标准方式，会中断当前语句并回滚该行操作。第二，UPDATE触发器中加了NEW.user_id <> OLD.user_id的判断，避免无关字段的更新也触发一次父表查询，减少不必要的开销。第三，如果业务允许user_id为空，还需要先判断NEW.user_id IS NOT NULL再查询，空值在外键语义中通常是不校验的。
再看SQL Server的写法，它没有SIGNAL语句，需要借助RAISERROR配合回滚，且SQL Server的触发器是语句级的，需要处理inserted伪表：
CREATE TRIGGER trg_orders_check
ON orders
FOR INSERT, UPDATE
AS
BEGIN
SET NOCOUNT ON;
IF EXISTS (
SELECT 1 FROM inserted i
LEFT JOIN users u ON u.id = i.user_id
WHERE u.id IS NULL AND i.user_id IS NOT NULL
)
BEGIN
RAISERROR('外键校验失败：user_id在users表中不存在', 16, 1);
ROLLBACK TRANSACTION;
END
END
SQL Server的语句级触发器天然支持批量插入的校验，一次插入一万行也只需要一次JOIN判断，这是它相比MySQL行级触发器的性能优势。MySQL 5.x的FOR EACH ROW触发器在批量插入时会对每一行都执行一次父表查询，大批量导入时性能差距会很明显，这种场景建议临时禁用触发器或改用批量校验的存储过程。
在父表上编写DELETE和UPDATE触发器防止孤儿记录
只校验子表写入还不够。外键约束的另一半作用是阻止父表删除或修改主键时留下孤儿记录，这需要在父表上创建BEFORE DELETE和BEFORE UPDATE触发器。核心思路是：删除或更新父记录前，检查子表中是否还有引用它的数据，有则阻止或做级联处理。
DELIMITER $$
CREATE TRIGGER trg_users_bd
BEFORE DELETE ON users
FOR EACH ROW
BEGIN
DECLARE child_count INT;
SELECT COUNT(*) INTO child_count FROM orders WHERE user_id = OLD.id;
IF child_count > 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '存在关联订单，禁止删除该用户';
END IF;
END$$
CREATE TRIGGER trg_users_bu
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
DECLARE child_count INT;
IF NEW.id <> OLD.id THEN
SELECT COUNT(*) INTO child_count FROM orders WHERE user_id = OLD.id;
IF child_count > 0 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '存在关联订单，禁止修改该用户主键';
END IF;
END IF;
END$$
DELIMITER ;
如果业务上希望删除用户时自动清理订单，相当于实现外键的ON DELETE CASCADE语义，可以把SIGNAL部分替换成删除逻辑：先删子表数据再放行父表删除。但要特别注意，MySQL不允许在同一个表的触发器中修改该表本身，不过在users表的触发器中删除orders表的数据是允许的，所以级联写法可以正常工作。写法如下：
CREATE TRIGGER trg_users_cascade_bd
BEFORE DELETE ON users
FOR EACH ROW
BEGIN
-- 级联删除关联订单，模拟 ON DELETE CASCADE
DELETE FROM orders WHERE user_id = OLD.id;
DELETE FROM addresses WHERE user_id = OLD.id;
END
级联写法虽然方便，但风险比阻止式更高。一旦触发器中的DELETE漏掉某张子表，就会产生新的孤儿数据，而且这种错误不会报错，只能靠定期跑数据一致性检查脚本来发现。建议在代码评审时把所有引用users表的表列出来逐一核对，或者维护一张引用关系元数据表，触发器通过查元数据动态处理，不过动态SQL会让逻辑更复杂，一般还是显式写清楚更稳妥。
触发器方案的坑点与性能优化建议
第一个坑是递归触发。某些数据库（如SQL Server默认关闭、PostgreSQL默认开启）允许触发器再触发其他触发器，如果两张表互相用触发器校验对方，可能形成死循环或超出递归深度限制。MySQL本身不允许触发器递归调用，这一点相对安全，但SQL Server一定要确认RECURSIVE_TRIGGERS选项处于关闭状态。
第二个坑是批量导入性能。前面提到MySQL行级触发器在批量插入时开销大，实测中十万行导入可能从两秒膨胀到二十秒。优化手段有三种：导入前用SET FOREIGN_KEY_CHECKS类似的开关临时禁用触发器（MySQL可用DROP TRIGGER再重建，或把校验逻辑放到LOAD DATA之后跑一次批量核对）；把COUNT查询改为EXISTS半连接，减少扫描量；给子表的外键列建索引，否则父表触发器里的子表查询会全表扫描，这是最容易被忽略的一条。
第三个坑是一致性窗口问题。触发器的校验查询和业务语句在同一个事务中执行，读的是当前会话可见的数据，这点和原生外键一致，基本不会出现校验通过但数据又被别的事务删掉的竞态——前提是父表删除也被触发器拦住了。所以子表和父表的触发器必须成对创建，只做一半等于没做。上线后可以用SHOW TRIGGERS（MySQL）或sys.triggers（SQL Server）核对清单，再配合定期跑孤儿记录检测SQL兜底，形成完整的引用完整性防护网。
总结一下，触发器替代外键约束是一个权衡型方案：换来了跨库部署能力和灵活的业务校验规则，付出了额外的性能开销和维护成本。如果系统是单库且并发不高，优先用原生外键；如果是分库分表或者需要在校验中加入业务逻辑，触发器方案配合严格的索引和监控，完全可以做到接近外键的可靠性。