外键不是“可选项”，而是数据不被搞乱的保险丝
MySQL里设外键，核心就一个目的：阻止出现“查得到订单，却找不到客户”的脏数据。它不是锦上添花的功能，而是防止业务逻辑崩塌的底层约束。一旦关掉外键（比如用MyISAM引擎、或手动禁用
FOREIGN_KEY_CHECKS），插入一条
customer_id = 999的订单就毫无阻力——哪怕
customers表里压根没这个人。这种“孤儿记录”后续会引发查询错觉、统计偏差、应用层反复兜底，比性能损耗更难排查。
为什么外键经常“不生效”？三个硬性前提缺一不可
很多人执行了
ALTER TABLE orders ADD FOREIGN KEY (customer_id) REFERENCES customers(id)，却发现约束没起作用。常见原因有： 引擎不是
InnoDB——
MyISAM完全不支持外键，建了也白建；检查用
SHOW CREATE TABLE orders看
ENGINE=InnoDB是否在场 外键列和主键列类型不严格一致——
INT对
TINYINT不行，
INT UNSIGNED对
INT也不行，连符号位都得对齐 父表主键缺失或不是
PRIMARY KEY/
UNIQUE——外键只能引用主键或带唯一索引的列，普通
INDEX无效
ON DELETE CASCADE 看似方便，实则高危操作
加了
ON DELETE CASCADE，删一个客户，所有订单自动消失。听起来很省事，但实际生产中极易误删。比如某次脚本漏写了
WHERE条件，
DELETE FROM customers直接清空整张表，下游订单全军覆没。更稳妥的做法是： 默认用
ON DELETE RESTRICT（或不写，默认行为），强制业务层显式处理关联数据 真需要级联时，先在事务里
SELECT COUNT(*)确认影响行数，再执行 避免在大表上用
CASCADE——删除主表一行可能触发子表百万行扫描+更新，锁表时间远超预期
外键带来的隐性成本：索引、性能与迁移陷阱
MySQL会在外键列上自动建索引，这是好事，但也意味着：
每个外键都多占一份磁盘空间，高频更新的外键列可能成为写入瓶颈 大批量导入数据（如ETL）时，逐条校验外键会拖慢10倍以上——应临时关闭SET FOREIGN_KEY_CHECKS = 0，导入完再开 跨库无法建外键（MySQL不支持），如果未来要分库分表，现在依赖外键的强一致性设计就得推倒重来
真正关键的不是“要不要外键”，而是想清楚：你依赖的是数据库帮你拦住错误，还是靠应用层自己兜底。前者干净但受限，后者灵活但容易漏。选哪条路，得看团队对数据质量的容忍底线在哪里。
