MySQL外键仅InnoDB支持，要求主子表字段类型、字符集、排序规则完全一致且均有索引；级联行为影响数据一致性和性能；禁用外键检查或LOAD DATA时易致约束失效；外键不跨库、不校验JSON，仅为数据库层兜底。
外键定义时必须满足哪些硬性条件
MySQL 中的外键不是加了 FOREIGN KEY 就能生效——它只在 InnoDB 引擎下有效，MyISAM 完全忽略外键约束。另外，被引用的字段（通常是主表的 PRIMARY KEY 或 UNIQUE 索引列）和外键列必须严格匹配：类型一致（比如都是 INT UNSIGNED，不能一边是 INT 一边是 BIGINT）、字符集和排序规则相同（尤其在 VARCHAR 字段上容易踩坑）、且都建了索引（外键列本身也需单独建索引，否则建表失败）。
常见错误现象：ERROR 1005 (HY000): Can't create table `db`.`t2` (errno: 150 "Foreign key constraint is incorrectly formed")，基本就是上述某一项没对齐。
- 检查引擎：
SHOW CREATE TABLE parent_table;确认是ENGINE=InnoDB - 确认类型完全一致：
DESCRIBE parent_table;和DESCRIBE child_table;对比字段定义 - 确保父表被引用列有
UNIQUE或PRIMARY KEY约束，子表外键列自己也要有索引（CREATE INDEX idx_fk ON child_table (parent_id);）
ON DELETE 和 ON UPDATE 的行为选择直接影响业务逻辑
外键的级联动作不是“可有可无”的配置项，而是数据一致性策略的核心部分。比如订单表 orders 外键关联用户表 users(id)，如果用户被删除，你希望订单保留还是一并清理？这决定了该用 ON DELETE RESTRICT（默认，禁止删）、ON DELETE CASCADE（连带删），还是 ON DELETE SET NULL（设为空，前提是外键列允许 NULL）。
性能影响：级联操作（尤其是 CASCADE）会在执行时隐式触发多表写入，可能延长事务时间、增加锁持有范围；而 RESTRICT 虽安全，但业务层需先手动处理子记录，否则 DELETE FROM users WHERE id = 123 直接报错。
-
ON DELETE CASCADE适合强生命周期绑定场景（如日志明细依赖日志头） -
ON DELETE SET NULL适合需要保留历史归属但允许“归属丢失”的情况（如员工离职后工单仍保留，但assignee_id设为NULL） - 避免在高并发写入的父表上滥用
CASCADE，容易引发锁竞争
外键失效的典型误操作场景
即使建表时外键语法正确，运行中也可能“形同虚设”。最常见的是使用 ALTER TABLE ... DISABLE KEYS 或直接关闭外键检查：SET FOREIGN_KEY_CHECKS = 0;。这个开关是会话级的，一旦关闭，后续所有 INSERT/UPDATE/DELETE 都跳过外键校验——很多批量导入脚本为了提速会关掉它，但忘记恢复，导致脏数据悄悄入库。
另一个隐蔽问题：使用 LOAD DATA INFILE 导入时，默认不触发外键约束检查（即使 FOREIGN_KEY_CHECKS = 1），必须显式加上 SET FOREIGN_KEY_CHECKS = 1; 并确认导入前后状态一致。
- 上线前检查：
SELECT @@FOREIGN_KEY_CHECKS;应为1 - 批量操作后务必验证：
SELECT COUNT(*) FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table); - 不要在应用代码里随意执行
SET FOREIGN_KEY_CHECKS = 0，除非你清楚后果且有回滚方案
外键与应用层校验的边界在哪
外键解决的是“数据库层面的参照完整性”，不是业务完整性。它无法保证语义合理性：比如订单表外键指向商品表，能防止插入不存在的商品 ID，但不能阻止你把一个已下架（status = 'offline'）的商品加入新订单。这类逻辑必须由应用层或存储过程控制。
更关键的是，外键无法跨库（FOREIGN KEY 只支持同库内表引用），也无法约束 JSON 字段里的 ID 值——哪怕你存了个 {"product_id": 999}，外键也完全看不见。
- 外键是兜底手段，不是唯一防线；关键业务流程仍需应用层做存在性 + 状态双重校验
- 分库架构下，外键失去意义，得靠分布式事务或最终一致性方案替代
- 涉及动态结构（如插件化扩展表）时，硬外键会极大限制灵活性，此时应让步给松耦合设计
真正难的从来不是加一条 FOREIGN KEY，而是想清楚：这条约束代表什么业务承诺，谁来负责它的生命周期，以及当它被绕过时系统是否还能稳住。
