MySQL外键需满足四条件：父表被引列须有索引、同为InnoDB引擎、字段类型字符集排序规则严格一致、NULL约束逻辑匹配；级联操作各具风险；大厂禁用主因性能、分布式扩展与运维复杂度；可用应用校验、巡检脚本等替代。
MySQL 外键不是“加了就能用”，面试常考的恰恰是它在实际场景中的限制、陷阱和替代方案。
外键必须满足的四个基本条件
很多候选人只记得“字段类型要一致”，其实还有三个关键前提：
- 父表被引用的列必须有索引（通常是主键或唯一键），否则创建外键会失败
- 子表和父表必须使用 InnoDB 引擎（MyISAM 不支持外键）
- 关联字段的数据类型、字符集、排序规则必须严格一致（比如 INT 和 BIGINT 不行，utf8mb4_general_ci 和 utf8mb4_unicode_ci 也不行）
- 字段是否允许 NULL 要匹配逻辑：若子表外键列允许 NULL，删除父表记录时可设为 NULL（需指定 ON DELETE SET NULL）；若不允许 NULL，则必须提前处理子表数据
ON DELETE / ON UPDATE 的常见组合与风险
面试官喜欢问“删用户时订单怎么处理”，本质是考察你对级联行为的理解和权衡：
- ON DELETE CASCADE：自动删子记录。适合强生命周期绑定（如日志明细随任务删除），但误删父记录会导致数据大面积丢失，生产环境慎用
- ON DELETE RESTRICT / NO ACTION：默认行为，父记录有子数据时禁止删除。安全但体验差，需应用层先清理子表
- ON DELETE SET NULL：要求外键列允许 NULL。适合“软解绑”场景（如员工离职后订单保留但归属清空），但需确保业务逻辑能正确处理 NULL 值
- ON UPDATE CASCADE：修改父表主键时同步更新子表。极少使用——主键本不该频繁变更；若真要改，更推荐用不变的代理主键（如 id），而非业务字段（如 code）作主键
为什么大厂线上库往往禁用外键？
这不是技术不行，而是权衡后的工程选择：
- 性能影响：每次 INSERT/UPDATE/DELETE 都要校验外键约束，高并发写入时锁范围扩大（InnoDB 会对父表相关记录加共享锁），可能成为瓶颈
- 分布式扩展难：分库分表后，跨库外键无法由数据库保证，最终一致性需应用层兜底，外键反而变成累赘
- 运维复杂度高：导入数据、交换分区、主从切换时，外键容易导致操作失败；DBA 更倾向用脚本+应用层校验来控制数据质量
- 职责分离：现代架构强调“数据库只存数据，逻辑在服务层”。外键把部分业务规则耦合进存储层，不利于微服务拆分和灰度发布
不用外键，如何保证参照完整性？
这是面试加分项——说明你懂替代方案，且知道每种的适用边界：
- 应用层强校验：操作子表前，先查父表是否存在（注意加缓存避免压垮数据库）；配合事务保证原子性
- 定时巡检脚本：每日跑 SQL 找出“孤儿记录”，告警或归档。适合对实时性要求不高的后台系统
- 数据库触发器（谨慎使用）：模拟外键行为，但会隐藏逻辑、难以调试，且同样有性能开销
- 唯一约束 + 应用层约定：对高频查询的维度表（如商品类目），用唯一索引加速验证，并在 SDK 或 ORM 层统一拦截非法值
外键本身没有错，错的是脱离场景谈功能。面试回答时，少说“应该用”，多讲“什么情况下值得用、什么情况下该放弃、放弃后怎么补足”。
