外键约束在 InnoDB 中必须显式启用
MySQL 默认启动时并不强制所有表使用外键约束，即使你用了
FOREIGN KEY语法建表，InnoDB 也可能不实际执行检查——前提是
FOREIGN_KEY_CHECKS被设为
0或者建表时没启用严格模式。
常见错误现象：插入子表记录时没报错，但父记录根本不存在；或者删了父记录，子记录却还留着，看起来“外键没起作用”。
检查当前状态：SELECT @@FOREIGN_KEY_CHECKS;临时开启（会话级）：
SET FOREIGN_KEY_CHECKS = 1;永久生效需在
my.cnf中添加：
innodb_force_foreign_keys = ON（MySQL 5.6.16+ 支持） 建表时确保引擎和约束语法完整：
CREATE TABLE orders ( id INT PRIMARY KEY, user_id INT, FOREIGN KEY (user_id) REFERENCES users(id) ) ENGINE=InnoDB;
外键操作触发的隐式事务行为
InnoDB 的外键级联动作（如
ON DELETE CASCADE）不是“自动拼 SQL”，而是由存储引擎在事务内部统一调度。这意味着一次
DELETE可能引发多张表的行变更，并全部包裹在同一个事务中。
容易踩的坑：以为
CASCADE是“事后清理”，结果发现它也受锁机制影响，甚至可能造成锁等待或死锁。
ON UPDATE CASCADE和
ON DELETE CASCADE都会在父表操作时，同步更新/删除子表匹配行，且不可回滚单个子表动作 若子表数据量大，
CASCADE可能长时间持有
FOR UPDATE锁，阻塞其他读写 没有
CASCADE时，
DELETE FROM parent会直接报错：
Cannot delete or update a parent row: a foreign key constraint fails用
SHOW ENGINE INNODB STATUS\G查看最近死锁时，常能看到外键触发的锁等待链
外键字段类型与索引要求必须严格一致
InnoDB 要求外键列和被引用列不仅逻辑语义相同，连数据类型、字符集、排序规则、是否允许 NULL 都得完全匹配，否则建表失败或约束无效。
典型报错：
ERROR 1005 (HY000): Can't create table `db`.`t2` (errno: 150 "Foreign key constraint is incorrectly formed")检查字段类型是否一致：
user_id INT不能引用
id BIGINT，哪怕值域重叠也不行 字符集必须相同：父表用
utf8mb4_unicode_ci，子表外键也得是同一 collation 被引用列必须有索引（通常是主键或唯一索引），否则外键无法创建 如果父表是
INT UNSIGNED，子表外键也必须声明
UNSIGNED，否则报错
事务中禁用外键检查的风险点
有些迁移脚本会用
SET FOREIGN_KEY_CHECKS = 0临时绕过约束，再批量导入数据。这本身没问题，但极易留下数据一致性隐患。
关键问题不在“能不能关”，而在于“关了之后有没有人记得开、有没有人验证数据是否真合规”。
该设置只对当前会话有效，应用连接池复用连接时，可能某个连接残留0状态，后续 DML 意外跳过检查 关闭后插入非法数据，后续再开也无济于事——InnoDB 不会自动扫描校验历史数据 用
mysqldump --skip-foreign-key-checks导出时，恢复前务必确认目标库
FOREIGN_KEY_CHECKS为
1，否则 dump 文件里的
SET FOREIGN_KEY_CHECKS=0会生效 真正安全的做法：用事务 + 显式检查代替全局关闭，例如先
SELECT id FROM parent WHERE id = ?再插入子表 外键不是银弹，它保障的是 DML 时刻的参照完整性，而不是替代应用层的数据校验逻辑。尤其在分库分表、读写分离或异步复制场景下，外键约束的实际作用范围非常有限。真正难处理的，往往是那些跨事务、跨服务、跨数据库的一致性问题。
