外键约束在InnoDB中需显式启用且字段类型、索引等必须严格匹配，否则无效；级联操作具事务性并可能引发锁争用；禁用检查易致数据不一致，不可替代应用层校验。
外键约束在 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 = ?再插入子表
