最常见原因是子表存在“孤儿记录”，即外键值在主表中不存在；此外还需满足：引擎为innodb、数据类型及长度完全一致、被引用列和外键列均有索引、null约束匹配。
直接加会失败，除非数据干净、类型匹配、索引到位、引擎支持——否则 ALTER TABLE ... ADD FOREIGN KEY 会报错 547 或类似约束冲突。
为什么 ALTER TABLE ADD FOREIGN KEY 总是报错？
最常见原因是：目标表（主表）和当前表（子表）中已有数据，但存在“孤儿记录”——即子表某行的外键值，在主表对应列中根本不存在。
其他硬性前提也常被忽略：
- 两张表都必须是
InnoDB引擎（MyISAM不支持外键） - 外键列和被引用列的数据类型、长度、符号（如
UNSIGNED）必须完全一致 - 被引用列（通常是主表主键或唯一键）必须已建索引；外键列本身也需有索引（MySQL 5.6+ 会自动补，但旧版本要手动加）
- 外键列不能为
NULL时，若已有NULL值，也会被拒绝（取决于是否允许空值）
怎么让已有数据的表成功加外键？
核心思路：先清理/对齐数据，再执行语句。不要跳过验证步骤。
- 查出所有“不匹配”的记录：
SELECT s.classNo FROM Student s LEFT JOIN Class c ON s.classNo = c.classNo WHERE c.classNo IS NULL; - 删掉或修正这些行（比如设为合法值、或删掉整行），确保每条
classNo都能在Class表中找到 - 确认主表
Class(classNo)是主键或有唯一索引：SHOW INDEX FROM Class WHERE Column_name = 'classNo'; - 给子表外键列加索引（如果还没）：
CREATE INDEX idx_classno ON Student(classNo); - 最后执行：
ALTER TABLE Student ADD FOREIGN KEY (classNo) REFERENCES Class(classNo) ON DELETE RESTRICT ON UPDATE CASCADE;
ON DELETE / ON UPDATE 选哪个？
这决定父表变更时子表如何响应，不是可选项，而是行为关键点：
-
ON DELETE RESTRICT（默认）：父表某行被删前，先检查子表有没有引用它；有就直接报错，安全但操作繁琐 -
ON DELETE CASCADE：父表删一行，子表所有关联行自动删掉；适合强生命周期绑定（如订单 → 订单项），但误删风险高 -
ON DELETE SET NULL：要求外键列允许NULL；父表删了，子表该字段变NULL，适合软解耦场景 -
ON UPDATE CASCADE很少用，除非主键确实会变（不推荐）；多数情况应避免更新主键值
加完外键后怎么验证和维护？
加完不等于万事大吉。外键是约束，不是装饰：
- 用
SHOW CREATE TABLE Student;确认外键已生效，并记下系统生成的约束名（如fk_student_classno） - 删外键必须用约束名，不能只靠列名：
ALTER TABLE Student DROP FOREIGN KEY fk_student_classno; - 批量导入数据前，建议临时禁用外键检查：
SET FOREIGN_KEY_CHECKS = 0;，导入完再SET FOREIGN_KEY_CHECKS = 1;，但务必确保数据逻辑自洽 - 外键会拖慢 INSERT/UPDATE/DELETE，尤其大表高频写入时；监控
Handler_commit和锁等待时间，别盲目加
真正容易被忽略的是：外键不是银弹。它保障一致性，但也把应用层本可灵活处理的逻辑，硬塞进数据库执行路径里。上线前，一定在测试库用真实数据跑一遍全链路增删改，看错误是否按预期抛出、级联是否真按你写的走——纸上写的 CASCADE，和实际删掉 2000 行订单再删掉 1 万条明细，是两回事。
