MyISAM不支持外键是设计选择而非bug，因其专注快速读取而舍弃事务、行锁和引用完整性；InnoDB外键生效需满足三前提：主表字段为主键或唯一索引、字段类型及字符集完全一致、从表数据在主表中已存在。
MyISAM 确实不支持外键，这不是 bug，是设计选择
MySQL 的 MyISAM 引擎从诞生起就没实现外键约束逻辑——它压根不处理引用完整性校验，也不维护父子表之间的关联状态。这和事务、行锁一样，属于被主动舍弃的能力。所以当你执行 ALTER TABLE ... ADD FOREIGN KEY 却收到 “ERROR 1005 (HY000): Can't create table” 或 “Unsupported engine for foreign key” 时，并不是语法写错了，而是引擎不认这个指令。
-
MyISAM的核心目标是“快读”，所有设计都围绕减少开销：没事务日志、没行锁、没崩溃恢复，自然也没外键验证成本 - 如果你在建表时没指定
ENGINE=InnoDB，而 MySQL 版本较老（如 5.5 之前），默认就是MyISAM，极易踩坑 - 即使把
MyISAM表改成InnoDB，也得检查字段类型、索引、数据一致性——改引擎只是必要条件，不是充分条件
InnoDB 外键真正起作用的 3 个前提
就算你用了 InnoDB，外键也不会自动生效。它只在满足三个硬性条件时才被 MySQL 接受并强制校验：
- 主表被引用字段必须是
PRIMARY KEY或带UNIQUE约束的索引（不能只是普通INDEX） - 从表外键字段和主表被引用字段必须严格一致：类型相同（
INT(11) UNSIGNED≠INT(11)）、字符集相同（utf8mb4≠utf8）、排序规则（collation）一致 - 从表当前所有外键字段值，必须已在主表对应字段中存在；否则添加外键会直接报错
ERROR 1452 (23000): Cannot add or update a child row
例如：users(id INT PRIMARY KEY) 和 orders(user_id TINYINT) 就无法建立外键，哪怕 user_id 全部有值——类型不兼容，MySQL 连解析都不会通过。
外键不是“加了就安全”，ON DELETE/UPDATE 行为决定实际效果
很多人以为加上外键就万事大吉，其实最关键的其实是级联动作。没有明确定义 ON DELETE 和 ON UPDATE，MySQL 默认用 RESTRICT（拒绝操作），这在业务上可能比没外键还危险——删个用户失败，但程序没捕获异常，后续逻辑就断了。
-
ON DELETE CASCADE：删主表记录时，自动删所有关联子记录（适合订单-订单项这类强生命周期绑定） -
ON DELETE SET NULL：要求外键字段允许NULL；删主表后，子表该字段置空（适合“最后编辑人”这类弱引用） -
ON DELETE RESTRICT：默认行为，任何违反引用的操作都会被拦住（适合需要人工干预的场景，比如删除部门前必须先迁移员工）
注意：CASCADE 在大数据量下可能触发长事务或锁表，线上慎用；SET NULL 要提前确保字段定义含 NULL，否则建外键会失败。
为什么生产环境常禁用外键？不是它没用，而是代价显性化
外键的约束逻辑是在 InnoDB 层实时执行的，每次 INSERT/UPDATE/DELETE 都要跨表查、加锁、校验。这在高并发写入场景下会成为瓶颈，尤其当主表被频繁更新，而多个子表都依赖它时。
- 外键会阻止某些优化：比如无法对主表做
TRUNCATE（必须先删子表或去外键），也无法用LOAD DATA INFILE直接灌数据（除非先关外键检查） - 应用层做一致性控制更灵活：比如批量导入时跳过校验，事后统一修复；或者用消息队列异步解耦，避免数据库层强阻塞
- 外键错误信息不够友好：
ERROR 1452不告诉你哪条数据违规，排查要手动写NOT IN子查询，效率低
真正容易被忽略的是：一旦你在开发库加了外键，又没在部署脚本里同步处理，上线时很可能因引擎、字符集或数据不洁直接失败——这种问题不会出现在单元测试里，只会在凌晨三点的发布窗口爆发。
