MySQL 1-2-1链式外键更新父表约束失败原因及解决办法

这个问题是MySQL InnoDB引擎的外键约束校验机制和级联更新执行逻辑共同导致的：

• InnoDB的外键级联操作按外键定义的顺序逐表执行，不会预先规划所有级联节点的更新顺序。
• 外键约束校验是即时执行的：每完成一张表的级联更新后，会立刻校验所有关联该表的外键约束，不会等整个级联链路的所有更新操作全部完成后再统一校验。

对应你的1-2-1结构，更新p_table主键的执行流程如下：

1. 完成p_table的p_table_id更新：从3改为3333
2. 按外键定义顺序，先级联更新c_table的p_table_id为3333，c_table更新完成
3. 此时InnoDB立即校验所有依赖c_table的外键：也就是cc_table关联c_table的外键，此时cc_table的p_table_id仍为3，已经无法匹配c_table中更新后的3333，直接触发1452约束校验失败错误，后续级联更新c2_table、cc_table的逻辑完全不会执行。

其他结构没有这个问题的原因也很明确：单链式（1-1-1）、单表多父表（1-2）、多表单子表（2-1）的结构中，不会出现「单个子表字段需要同时匹配两个处于中间不一致状态的父表字段」的场景，校验逻辑可以正常通过。

可以根据你的业务场景选择以下方案：

方案1：临时关闭会话级外键校验（最简单） #

MySQL的foreign_key_checks参数是会话级生效的，临时关闭后执行更新，完成后再开启即可绕过中间状态的校验，只要你的数据本身逻辑一致，不会出现数据损坏问题，级联更新逻辑也会正常执行：

-- 当前会话关闭外键校验
SET FOREIGN_KEY_CHECKS = 0;
-- 执行更新操作
UPDATE p_table SET p_table_id = 3333 WHERE p_table_id = 3;
-- 恢复外键校验
SET FOREIGN_KEY_CHECKS = 1;

方案2：调整表结构设计（最稳妥，符合范式规范） #

不要让cc_table的同一个字段同时关联两个父表的主键，拆分字段分别关联即可从根本上避免中间状态不一致的问题：

-- 修改cc_table结构示例
ALTER TABLE cc_table 
ADD COLUMN c_table_id INT NOT NULL,
ADD COLUMN c2_table_id INT NOT NULL,
DROP COLUMN p_table_id,
ADD FOREIGN KEY (c_table_id) REFERENCES c_table(p_table_id) ON UPDATE CASCADE ON DELETE RESTRICT,
ADD FOREIGN KEY (c2_table_id) REFERENCES c2_table(p_table_id) ON UPDATE CASCADE ON DELETE RESTRICT;

方案3：用触发器替代外键级联更新（可控性最高） #

如果必须保留原有表结构，可以停用原有的外键级联规则，自定义触发器控制更新顺序：先更新p_table，再同时更新c_table、c2_table，最后更新cc_table的关联字段，全程在事务中执行即可保证一致性。

内容的提问来源于stack exchange，提问作者Payel Senapati