能实现，但不推荐作为外键的替代方案——它只在应用层无法控制、又必须绕过物理外键时才考虑，且必须严格规避递归、死锁和性能陷阱。
直接给出结论：利用触发器模拟外键约束，技术上虽然可行，但绝不应该作为物理外键的常规替代品。它唯一适用的场景是——应用层已无法有效管控，同时又无法部署物理外键，还不得不硬性保证数据一致性。而且，一旦采用触发器方案，递归触发、死锁风险、性能急剧下降这些隐患，一个都不能忽视。
触发器模拟外键时为何容易报 ERROR 1452 却不生效？
很多人会误以为：既然触发器能在事件发生时自动执行，那就能直接阻止非法数据。但关键在于，触发器本身并不拦截非法插入，它仅仅是在事件发生后做“事后补救”。举个例子，向 scores 表插入一条 NAME 字段的值，而这个值在 students 表中根本不存在——INSERT 语句照样成功执行，触发器根本没有机会说“不”，它只能事后处理，或者手动抛出 SIGNAL 来中断操作。
- 想真正阻止非法数据？必须使用
BEFORE INSERT或BEFORE UPDATE触发器，结合SIGNAL SQLSTATE '45000'主动报错，才能拦截写入。 AFTER类型的触发器呢？适合做同步、记录日志、统计汇总等操作，但想靠它拦截非法数据落库？完全行不通。- 校验逻辑必须直接写在触发器体内。MySQL 8.0+ 虽然支持存储函数，但跨版本兼容性较差，不建议引入额外复杂度。
BEFORE INSERT 触发器中如何安全校验参照完整性？
核心思路很明确：通过 SELECT ... INTO 在父表中查找匹配记录，再决定是否允许写入。关键注意点——必须妥善处理 NOT FOUND 异常，否则触发器会因变量未赋值而直接中断，连错误信息都无法清晰给出。
DELIMITER $$
CREATE TRIGGER trg_check_student_ref BEFORE INSERT ON scores
FOR EACH ROW
BEGIN
DECLARE student_exists INT DEFAULT 0;
SELECT COUNT(*) INTO student_exists
FROM students WHERE NAME = NEW.NAME;
IF student_exists = 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'student not found in students table';
END IF;
END$$
DELIMITER ;
- 特别注意：不要在
IF条件中直接使用EXISTS子查询——MySQL 不支持这种写法，IF条件里无法嵌入子查询。 - 避免在触发器中调用存储函数做校验。如果函数内包含事务或锁操作，极易引发死锁。
- 还有一个重大隐患：高并发场景下，触发器的检查逻辑存在竞态条件——你刚查完父表记录还在，下一秒就被另一事务删除。物理外键天然能解决这个边界问题，而触发器却无能为力。
级联更新/删除时最容易踩的坑是什么？
不是逻辑写错，而是触发器自我触发（递归），或者锁等待堆积成雪崩。举例说明：UPDATE students 的触发器去更新 scores，而 scores 上的 UPDATE 又触发另一个触发器，形成链式调用——噩梦就此开始。
- MySQL 默认禁用递归触发器（
max_sp_recursion_depth = 0），但级联操作仍可能因为锁顺序不一致而引发死锁。 - 级联
UPDATE必须添加WHERE条件限定范围，例如只更新OLD.name = NEW.name对应的旧值。不加条件？全表扫描一遍，性能瞬间崩溃。 - 级联
DELETE建议使用BEFORE DELETE+DELETE FROM scores WHERE name = OLD.name，比AFTER更可控。 - InnoDB 对父表加的是共享锁，子表更新时需要排他锁。两个方向的锁请求一旦交错，通过
SHOW ENGINE INNODB STATUS就能看到触目惊心的死锁细节。
说到底，编写触发器本身并不困难，真正的挑战在于——你必须确保所有业务入口（批量导入、运维脚本、跨服务直连等）都无法绕过这个触发器。只要遗漏一个入口，数据就会失洽。物理外键哪怕性能差一些，也比依赖人工维护触发器逻辑可靠得多。
