外键字段update报错是因为参照完整性校验失败，即新值在父表中不存在或旧值已被删除；应先确保父表存在目标值再更新子表，或使用on update cascade级联更新。
UPDATE 外键字段时为什么报错？
直接执行 UPDATE child_table SET parent_id = 100 WHERE parent_id = 1 会失败，不是因为你改错了字段，而是数据库在检查约束时发现：新值 100 在父表里还不存在（或旧值 1 被删/改后子表仍引用它），触发了参照完整性校验。典型错误包括：ERROR 1451 (HY000)（MySQL）、update or delete on table "xxx" violates foreign key constraint（PostgreSQL）、The UPDATE statement conflicted with the REFERENCE constraint（SQL Server）。
先确保父表有目标值，再更新子表
这是最通用、最安全的做法，不依赖数据库特性，也不需要临时关约束。
- 先查父表：确认
parent_id = 100已存在于父表中，比如SELECT id FROM parent_table WHERE id = 100 - 如果不存在，必须先插入或启用对应记录（不能跳过这步）
- 再执行子表更新：
UPDATE child_table SET parent_id = 100 WHERE parent_id = 1 - 整个操作建议包在事务里，尤其当你要批量更新多个外键值时
ON UPDATE CASCADE 是唯一能“自动同步”的方式
它不是运行时加的补丁，而是在建表或 ALTER TABLE 时就定义好的行为。一旦设了 ON UPDATE CASCADE，你只改父表主键，子表外键字段会自动跟着变。
- 建表时写法：
FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON UPDATE CASCADE - 已有表添加（MySQL/PostgreSQL/SQL Server 均支持）：
ALTER TABLE child_table DROP CONSTRAINT fk_name; ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON UPDATE CASCADE - 注意：SQL Server 要求被引用列是主键或有唯一索引；PostgreSQL 和 MySQL 同样要求父列表有唯一性约束
- 没设这个选项的表，运行时无法“现场开启”级联——别信网上说的
SET CASCADE这类伪命令
MySQL 临时关外键检查风险极高
SET FOREIGN_KEY_CHECKS = 0 看似快捷，但它是全局会话级开关，且跳过所有约束校验，极易埋雷。
- 它只在当前连接生效，不影响其他会话，但你自己后续的 INSERT/UPDATE 都可能写入非法数据
- 即使你立刻
SET FOREIGN_KEY_CHECKS = 1，中间产生的脏数据不会自动修复 - PostgreSQL 和 SQL Server 根本不支持该语法，强行套用会报错
- 真正要用，必须配完整流程：
BEGIN; SET ... = 0; UPDATE parent; UPDATE child; SET ... = 1; COMMIT;—— 但依然不推荐
外键约束冲突的本质不是语法问题，而是数据状态不满足参照完整性。绕过校验不如理清依赖顺序，尤其是生产环境，多一次 SELECT 比事后修数据便宜得多。
