外键是否创建成功需三重验证：结构上检查SHOW CREATE TABLE是否有FOREIGN KEY定义，引擎与字段类型是否严格匹配（同为InnoDB、数据类型/符号位/字符集一致），数据上清除子表中的孤儿记录并确保FOREIGN_KEY_CHECKS=1。
确认外键是否真的被创建成功
很多“失效”其实是根本没建上——SHOW CREATE TABLE child_table 返回结果里压根没有 FOREIGN KEY 定义，说明建表或 ALTER TABLE 时已静默失败。常见原因包括：
- 父表未启用
InnoDB引擎（比如是MyISAM），SHOW TABLE STATUS LIKE 'parent_table'查看Engine字段 - 被引用列（如
users.id）不是主键且无UNIQUE索引，SHOW INDEX FROM users WHERE Key_name = 'PRIMARY' OR Non_unique = 0可验证 - 外键字段类型不严格一致：比如父表是
INT UNSIGNED，子表用了INT，哪怕值相同也会拒绝建约束
检查 FOREIGN_KEY_CHECKS 是否被意外关闭
即使外键定义存在，若会话级变量 FOREIGN_KEY_CHECKS 为 0，所有 INSERT/UPDATE 都绕过校验，看起来就像“失效”。执行 SELECT @@FOREIGN_KEY_CHECKS 查当前值。注意：
- 它默认是 1，但可能被脚本、迁移工具或误操作设为 0 后未恢复
-
SET FOREIGN_KEY_CHECKS = 0只影响当前会话，不会波及其它连接 - 在事务中设为 0 后若回滚，该变量仍保持 0，必须手动设回 1
验证父子表引擎与字符集是否完全一致
外键要求父子表不仅都是 InnoDB，还必须满足：
- 引擎完全一致：
ENGINE=InnoDB，不能一个写innodb（小写）一个写InnoDB（大小写混用在某些配置下会失败） - 字符集与排序规则一致：比如父表是
utf8mb4_unicode_ci，子表外键字段也必须是同一字符集+排序规则，SHOW FULL COLUMNS FROM child_table LIKE 'user_id'和SHOW FULL COLUMNS FROM parent_table LIKE 'id'对比 - 字段长度/精度匹配：如父表
VARCHAR(255)，子表外键不能是VARCHAR(191)（尤其在旧版本 MySQL 中）
修复已存在的数据不一致问题
即使结构全对，只要子表里存在父表中找不到的值，外键约束就无法启用或生效。运行以下语句定位“孤儿记录”：
SELECT child.id, child.user_id FROM orders child LEFT JOIN users parent ON child.user_id = parent.id WHERE parent.id IS NULL;
结果非空即表示数据违规。处理方式取决于业务逻辑：
- 删除非法行：
DELETE FROM orders WHERE user_id NOT IN (SELECT id FROM users) - 补全父表数据（慎用，需确认业务含义）
- 更新子表外键为合法值（如设为 NULL，前提是字段允许）
最后再试 ALTER TABLE orders ADD FOREIGN KEY (user_id) REFERENCES users(id) —— 这步只有在数据干净后才能成功。
最容易被忽略的是：外键约束不是“开关式”功能，它依赖结构一致性 + 数据一致性 + 运行时检查三者同时成立。少一个环节，就等于没约束。
