MyISAM忽略FOREIGN KEY语法是设计选择而非bug，因其未实现外键逻辑；InnoDB支持外键但需满足四前提：主表字段为主键或唯一索引、字段类型及字符集完全一致、从表数据在主表中已存在、FOREIGN_KEY_CHECKS开启。
MyISAM遇到FOREIGN KEY语法直接忽略，不报错也不校验
这不是 bug，是 MyISAM 的设计选择：它压根没实现外键逻辑。你写 FOREIGN KEY (user_id) REFERENCES users(id)，MyISAM 会当成注释处理——SHOW CREATE TABLE 里看不到该定义，INFORMATION_SCHEMA.KEY_COLUMN_USAGE 查不到记录，插入 user_id = 999999 这种明显不存在的值也完全放行。
常见误判场景包括：
- 用
mysqldump导出再导入，恢复后表引擎自动变成MyISAM（尤其老版本默认配置） - 建临时表时显式指定
ENGINE=MyISAM，后续拿它 JOIN 主业务表，非法关联被带入结果 - 历史遗留表未迁移，和新
InnoDB表混用，外键只管得着一半
切换到InnoDB后仍失败，大概率卡在四个硬性条件上
就算改了引擎，ALTER TABLE ADD FOREIGN KEY 还是报错（常见 errno 1215 或 3780），说明底层约束没对齐。必须同时满足：
- 主表被引用字段必须是
PRIMARY KEY或带UNIQUE约束的索引（普通INDEX不行） - 从表外键字段与主表字段类型**完全一致**：类型（
INTvsTINYINT）、长度（INT(10)vsINT(11)）、符号性（UNSIGNED必须两边都有或都没有）、字符集（推荐统一utf8mb4）和排序规则（如utf8mb4_0900_ai_ci） - 从表已有数据时，所有外键值必须在主表中真实存在；否则先跑：
SELECT * FROM child_table WHERE fk_col NOT IN (SELECT pk_col FROM parent_table) - 从表外键字段建议单独加普通索引，否则
JOIN或DELETE主表时性能暴跌
FOREIGN_KEY_CHECKS 被关掉，外键形同虚设
即使 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，导入后务必手动开回
外键只在DML操作时起作用，TRUNCATE和ALTER TABLE不触发校验
这是容易被当作“失效”的盲区：外键约束只拦截 INSERT、UPDATE、DELETE，对以下操作完全无感：
-
TRUNCATE TABLE：直接删数据+重建表，绕过所有约束检查 -
ALTER TABLE ... DROP COLUMN或MODIFY COLUMN：可能破坏字段一致性却不报错 - 直连存储引擎的物理操作（如某些备份工具的裸页读取）
真正决定外键是否起效的，从来不是语法写没写对，而是引擎、字段匹配、运行时开关三者严丝合缝。最容易漏掉的永远是字符集/排序规则不一致，和 FOREIGN_KEY_CHECKS 那个看不见的 0。
