MySQL外键生效需满足五条件：①表引擎为InnoDB；②外键与被引用列类型严格一致；③被引用列有索引（主键/UNIQUE）；④子表现有数据须匹配父表；⑤正确设置ON DELETE/ON UPDATE行为。
外键怎么加才真正生效
mysql 中加了 foreign key 但没报错、也没拦住脏数据？大概率是表引擎不对或语法漏了关键部分。innodb 才支持外键，myisam 完全忽略它——哪怕你写了也白写。
- 建表时必须用
ENGINE=InnoDB，否则ALTER TABLE ... ADD FOREIGN KEY会静默失败（不报错但不生效） - 外键列和被引用列的数据类型要严格一致：比如
dept_id INT对应dept(id) INT，不能一边是TINYINT一边是INT - 被引用字段（如
dept.id）必须有索引，通常是主键或UNIQUE；否则 MySQL 拒绝创建外键 - 添加外键前，子表里已存在的数据必须能匹配父表当前值，否则
ALTER TABLE直接报错Cannot add or update a child row
级联更新/删除的四种行为怎么选
ON DELETE 和 ON UPDATE 后面跟的不是装饰词，是数据库执行动作的明确指令。选错会导致数据意外消失或置空，而且很难回滚。
-
ON DELETE CASCADE：删部门时自动删掉所有该部门员工。适合强生命周期绑定场景，但误删父记录 = 连坐式清空 -
ON DELETE SET NULL：删部门后，员工表dept_id变成NULL。前提是该字段允许为NULL，且业务上能接受“无部门”状态 -
ON DELETE SET DEFAULT：需提前给dept_id设默认值（如DEFAULT 0），且父表中必须真有 ID=0 的部门，否则插入/更新会失败 -
ON DELETE NO ACTION（默认）：不许删，直接报错。最安全，但也最“僵硬”，得先手动清理子数据
注意：ON UPDATE CASCADE 很少用——主键本不该频繁改；真要改编号，通常走逻辑重映射，而不是靠数据库自动同步。
图形化工具里点几下就完事？小心隐藏陷阱
Navicat、DBeaver 或 MySQL Workbench 的“可视化建关系”功能确实能生成外键，但默认几乎都不带 ON DELETE/ON UPDATE 行为，全是 NO ACTION。你以为点了“启用参照完整性”就万事大吉，其实只是开了个门缝。
- 工具生成的 SQL 常省略引擎声明，导出再导入可能变成 MyISAM 表，外键彻底失效
- 有些工具把外键名自动生成成类似
fk_123456，后期排查问题时根本看不出关联哪两张表 - 修改已有外键？图形界面基本不支持，必须手写
ALTER TABLE ... DROP FOREIGN KEY再重建，且原约束名得先查SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
什么时候干脆别用外键
外键不是银弹。高并发写入场景下，它会成为锁瓶颈；分库分表后，跨库外键无法实现；微服务架构里，表归属不同服务，数据库层强制约束反而破坏边界。
- 业务层已用事务+应用校验兜底（比如先查部门是否存在再插入员工），数据库外键就成了冗余检查
- 历史数据迁移、ETL 导入时，外键会大幅拖慢速度，临时禁用又容易遗漏恢复
- 使用 JSON 字段或宽表设计时，硬加外键既不现实也不合理
真正关键的不是“有没有外键”，而是“谁负责保证引用一致性”。如果团队习惯靠代码校验、测试覆盖和监控告警来守底线，那外键只是可选项，不是必选项。
