外键本质是强制的“引用检查”
外键不是语法糖，也不是可有可无的装饰——它是 MySQL（仅
InnoDB）对“某条记录是否真的存在另一张表里”做的实时校验。比如
orders.user_id设为外键指向
users.id，那插入
orders时若填了个不存在的
user_id，MySQL 直接报错：
Cannot add or update a child row: a foreign key constraint fails。这不是靠程序逻辑兜底，而是数据库层的硬性拦截。 它只在
InnoDB表生效，
MyISAM完全无视外键定义（即使你写了也不会报错，但也不起作用） 外键列必须显式建索引（
ALTER TABLE orders ADD INDEX idx_user_id (user_id)），否则建外键会失败 —— 即使字段名和主键一样，也不会自动索引 两边字段类型必须严格兼容：比如
INT和
TINYINT UNSIGNED不行，
BIGINT和
INT也不行；字符集、排序规则也得一致
ON DELETE / ON UPDATE 不是可选项，是行为开关
外键不加
ON DELETE或
ON UPDATE，就等于只开了“禁止非法插入”，但没管“父记录变了怎么办”。常见取值有：
RESTRICT（默认）：删/改父记录前，先查子表有没有引用，有就直接拒绝
CASCADE：父删，子自动删；父改主键值，子外键值跟着改（慎用！尤其改主键在生产环境几乎从不发生）
SET NULL：要求外键列允许
NULL；父删/改后，子表对应外键字段设为
NULL
NO ACTION：和
RESTRICT在 MySQL 中行为一致，语义上更偏向“由应用决定”，但实际仍是拒绝
举个真实场景：用户注销时想保留订单历史但断开归属，应设
ON DELETE SET NULL；而删除产品时连带清空库存记录，才用
CASCADE。别图省事全写
CASCADE，一个误删可能级联干掉几十张表的数据。
外键不是银弹，它和性能、迁移、ORM 都有摩擦
启用外键意味着每次 INSERT/UPDATE/DELETE 都要多一次关联表的索引查找和锁检查。高并发写入场景下，外键约束可能成为瓶颈，尤其是跨分片或大表 JOIN 的外键。
数据迁移或导入时，常因外键约束失败：先关约束SET FOREIGN_KEY_CHECKS = 0，导入完再开（但务必确认数据逻辑自洽） 很多 ORM（如 Django、Laravel Eloquent）默认不依赖外键做关系维护，而是靠代码层 join 和验证；这时外键反而成了部署负担，容易被忽略或漏建 分库分表、读写分离架构下，外键跨物理库根本不可用，此时必须退回到应用层一致性保障
ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE SET NULL ON UPDATE RESTRICT;
外键和主键、索引的关系常被混淆
主键一定是唯一 + 非空 + 自动建聚簇索引；外键只是普通字段，它本身不保证唯一、不强制非空（除非你额外加
NOT NULL），且必须手动建索引。很多人以为“加了外键就自动索引了”，结果上线后
JOIN慢得离谱，explain 一看
type: ALL—— 就是因为忘了给外键列加索引。 一对多关系中，外键在“多”的那张表上（如
orders.user_id） 一对一关系中，外键可放任一边，但通常放在“附属表”上，并加
UNIQUE约束 多对多必须拆成三张表，中间关联表的两个字段分别作为外键，各自索引 外键真正难的不是语法，是判断“这个关系到底该不该由数据库来强控”——业务规则变、数据规模涨、架构演进快，外键有时是护栏，有时是枷锁。建之前，先问一句：这条约束，五年后还成立吗？
