外键约束失败是因底层条件不满足而非语法错误，需按顺序验证：引擎是否为InnoDB、被引用列是否主键或唯一索引、字段类型是否严格一致、外键列是否有有效索引、FOREIGN_KEY_CHECKS是否启用、字符集与排序规则是否统一。
外键约束失败不是“语法错了”，而是 MySQL 在建表或加约束时，发现底层条件不满足，直接拒绝。排查必须按固定顺序逐项验证，跳过任意一环都可能白忙。
查 SHOW CREATE TABLE 确认外键是否真被创建成功
很多所谓“失效”其实是根本没建上——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（默认有符号），就会被拒
用 INFORMATION_SCHEMA 核对外键列索引状态
外键列有没有索引，不能只看 SHOW CREATE TABLE 里有没有显式 INDEX 语句。InnoDB 虽会为外键列自动建索引，但仅限于“该列未被任何已有索引覆盖前缀”的情况。一旦你给 (a, b) 建了联合索引，再把 b 设为外键，InnoDB 就不会额外建索引，b 单独走不了索引，就会退化成全表扫描 + 行锁升级风险。
执行以下查询确认外键列是否被有效索引：
SELECT kcu.COLUMN_NAME, kcu.REFERENCED_TABLE_NAME, kcu.REFERENCED_COLUMN_NAME,
IF(t.index_name IS NULL,'MISSING','OK') AS index_status
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu
LEFT JOIN (
SELECT TABLE_NAME, COLUMN_NAME, INDEX_NAME
FROM INFORMATION_SCHEMA.STATISTICS
WHERE SEQ_IN_INDEX = 1
) t ON kcu.TABLE_NAME = t.TABLE_NAME AND kcu.COLUMN_NAME = t.COLUMN_NAME
WHERE kcu.REFERENCED_TABLE_SCHEMA = 'your_db'
AND kcu.TABLE_NAME = 'child_table';
index_status 为 MISSING：必须立刻补索引，如 ALTER TABLE child_table ADD INDEX idx_fk_user_id (user_id)。
检查 FOREIGN_KEY_CHECKS 是否被意外关闭
即使外键定义存在，若会话级变量 FOREIGN_KEY_CHECKS 为 0，所有 INSERT/UPDATE 都绕过校验，看起来就像“失效”。执行 SELECT @@FOREIGN_KEY_CHECKS 查当前值。注意：
- 它默认是
1，但可能被脚本、迁移工具或误操作设为0后未恢复 -
SET FOREIGN_KEY_CHECKS = 0只影响当前会话，不会波及其它连接 - 在事务中设为
0后若回滚，该变量仍保持0，必须手动设回1
查 SHOW ENGINE INNODB STATUS\G 中的 LATEST FOREIGN KEY ERROR
SHOW ENGINE INNODB STATUS\G 输出里的 LATEST FOREIGN KEY ERROR 段是唯一能确认“外键检查是否已触发”的入口。它不会告诉你锁了哪几行，但会明确指出：
- 哪条
INSERT/UPDATE语句因哪个外键（CONSTRAINT_NAME）失败 - 引用了哪个父表字段
- 具体哪一列的值缺失或类型不匹配
这个日志段的关键价值在于帮你排除“是不是外键在作怪”——如果这里没记录，那问题大概率不在外键约束检查环节；如果这里有记录，且你同时观察到事务阻塞或死锁，就基本可以断定是外键隐式加锁参与了锁竞争。
最容易被忽略的是字符集和排序规则的一致性：父表字段是 utf8mb4_unicode_ci，子表外键字段哪怕只是 utf8mb4_general_ci，也会导致外键创建失败或运行时行为异常。这种差异不会报错，但会让索引失效，最终表现为“查得到却锁不住”。
