能实现，但不推荐作为外键的替代方案——它只在应用层无法控制、又必须绕过物理外键时才考虑，且必须严格规避递归、死锁和性能陷阱。
直接说结论：能实现，但不推荐作为外键的替代方案——它只在应用层无法控制、又必须绕过物理外键时才考虑，且必须严格规避递归、死锁和性能陷阱。
触发器模拟外键时为什么容易报 ERROR 1452 却不生效？
因为触发器本身不拦截非法插入，只在事件发生后补救。比如向 scores 表插入一个不存在于 students 表的 NAME，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 ;
- 不要用
EXISTS子句直接在IF中判断——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就能看到死锁详情
真正难的不是写触发器，而是确认所有业务入口（包括批量导入、运维脚本、跨服务直连）都绕不开它；一旦漏掉一个，数据就失洽。物理外键哪怕性能差一点，也比靠人维护触发器逻辑更可靠。
