myisam不支持外键是设计选择而非bug，因其专注快速读取而舍弃事务、行锁和引用完整性；innodb外键生效需满足四前提：主表字段为主键或唯一索引、字段类型及字符集完全一致、从表数据在主表中已存在、foreign_key_checks开启。
MyISAM 不支持外键约束，不是 MySQL 的 bug 或遗漏，而是设计选择——它压根没实现这套逻辑；InnoDB 支持，则是因为它从底层就围绕事务、引用完整性与并发安全构建。想让外键真正起作用，第一步不是调语法，是确认引擎。
MyISAM 对 FOREIGN KEY 语句的“静默忽略”行为
MyISAM 在解析 CREATE TABLE 或 ALTER TABLE ... ADD FOREIGN KEY 时，只要语法合法（比如字段存在），就不会报错，也不会报 warning。它只是把 FOREIGN KEY 关键字当注释处理：
- SHOW CREATE TABLE 输出里永远看不到 FOREIGN KEY 定义
- INFORMATION_SCHEMA.KEY_COLUMN_USAGE 查不到对应记录
- 插入不存在的外键值（如 user_id = 999999 但 users 表无此 ID）完全放行
- 即使你手写级联动作（ON DELETE CASCADE），也毫无效果
这种“假装支持”的设计，源于 MyISAM 的定位：面向只读、高速扫描、低复杂度场景，不承担数据关系校验责任。
InnoDB 实现外键依赖的四个硬性条件
InnoDB 虽然支持外键，但创建失败非常常见，错误号多为 1215 或 3780。必须同时满足：
- 主表被引用字段必须是 PRIMARY KEY 或带 UNIQUE 约束的索引（普通 INDEX 不行）
- 从表外键字段与主表字段类型**完全一致**：包括类型（INT vs TINYINT）、长度（INT(10) vs INT(11)）、符号性（UNSIGNED 必须两边都加或都不加）、字符集（推荐统一用 utf8mb4）和排序规则（如 utf8mb4_0900_ai_ci）
- 从表外键字段建议单独建普通索引（否则 JOIN 或 DELETE 主表时性能暴跌）
- 若从表已有数据，所有外键值必须在主表中真实存在；否则先清理：SELECT * FROM child_table WHERE fk_col NOT IN (SELECT pk_col FROM parent_table)外键“存在但不生效”的真实原因
即使SHOW CREATE TABLE 明确显示了 FOREIGN KEY 定义，也可能形同虚设：
- 检查 SELECT @@FOREIGN_KEY_CHECKS，返回 0 表示关闭
- 临时启用：SET FOREIGN_KEY_CHECKS = 1（仅当前会话）
- 永久启用需确认配置文件（如 my.cnf）里没有 foreign_key_checks = OFF
- 注意：mysqldump 导出默认会加 SET FOREIGN_KEY_CHECKS=0，导入后务必手动开回
外键不是开关一按就完事的机制——它依赖引擎能力、字段匹配、运行时状态三者严丝合缝。最容易被忽略的是字符集/排序规则不一致和 FOREIGN_KEY_CHECKS 的隐形关闭。
