外键约束失败主因是字段类型、索引、引擎、数据一致性四者不满足；必须严格匹配类型（含符号性）、被引用列须为PRIMARY/UNIQUE索引、双方均为InnoDB引擎，且无孤儿记录。
外键字段类型必须完全一致，连 UNSIGNED 都不能差
mysql 报 error 1005 (hy000): can't create table 或 error 1215 (hy000): cannot add or update a child row: a foreign key constraint fails，八成是两边字段类型对不上。不是“看起来都是 int 就行”，而是字节长度、符号性、是否为 zerofill 全得一模一样。
比如主表 id 是 INT UNSIGNED，子表的外键字段写成 INT（默认有符号），就会失败；又或者主表是 BIGINT(20)，子表用了 BIGINT(10)，也过不去——括号里的显示宽度不影响，但类型声明本身必须严格匹配。
- 用
SHOW CREATE TABLE 表名;分别查主表和子表字段定义，逐字比对INT/INT UNSIGNED、VARCHAR(255)/TEXT这类细节 -
TINYINT和SMALLINT不能互换，哪怕都存数字也不行 - 字符集和排序规则也要一致，比如
utf8mb4_unicode_ci和utf8mb4_general_ci虽然兼容，但外键要求完全相同
被引用字段必须有索引，且不能是普通 WHERE 索引
外键依赖的是“查找效率”，所以 MySQL 强制要求被引用的列（通常是主表的主键或唯一键）必须有索引。但注意：如果你手动加了个 INDEX (col)，它只是普通索引，不满足外键约束条件——只有 PRIMARY KEY 或 UNIQUE KEY 才行。
常见错误是主表有个 status 字段，你想着“我加个索引就能当外键”，结果执行 ADD FOREIGN KEY 直接报错 ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint。
- 检查主表：运行
SHOW INDEX FROM 主表名 WHERE Key_name != 'PRIMARY';，确认你要引用的字段出现在Key_name为PRIMARY或某个UNIQUE的行里 - 如果只是普通索引，删掉它：
DROP INDEX 索引名 ON 主表名;，再建唯一索引：CREATE UNIQUE INDEX idx_col ON 主表名 (col); - 复合唯一键也能当外键目标，但子表外键字段顺序和数量必须和它完全一致
添加外键前先关掉外键检查？别乱动 FOREIGN_KEY_CHECKS
有人遇到插入历史数据失败，就去设 SET FOREIGN_KEY_CHECKS = 0;，以为能绕过校验。这确实能让 ALTER TABLE ... ADD FOREIGN KEY 成功，但代价是：约束形同虚设，后续数据可能彻底乱套。
真正该用这个开关的场景只有一种：你确定主表和子表已有全部数据，且逻辑上已满足外键关系，只是还没建约束。这时候先关检查、加外键、再开检查，才算安全操作。
- 加外键前务必验证数据一致性：
SELECT 子表.外键字段 FROM 子表 LEFT JOIN 主表 ON 子表.外键字段 = 主表.id WHERE 主表.id IS NULL;，结果非空说明存在孤儿记录 - 如果真有脏数据，先清理或补全，再建外键；别靠关检查蒙混过关
-
FOREIGN_KEY_CHECKS是会话级变量，断开连接后自动恢复为 1，别指望它“永久关闭”
使用 InnoDB 是硬性前提，MyISAM 不支持外键
哪怕类型、索引全对了，如果其中一张表引擎是 MyISAM，ADD FOREIGN KEY 一定失败，报错信息里通常带 storage engine 关键词。
这是最隐蔽的坑之一：建表时没指定 ENGINE=InnoDB，MySQL 5.5+ 默认用 InnoDB，但某些旧配置或迁移脚本可能残留 MyISAM 表；或者 ALTER 表时忘了改引擎。
- 查引擎：
SHOW TABLE STATUS LIKE '表名';，看Engine列是不是InnoDB - 转引擎：
ALTER TABLE 表名 ENGINE=InnoDB;（注意：大表会锁表，生产环境慎用） - 建新表时显式写
ENGINE=InnoDB，别依赖默认值
