直接update父表主键会失败，因外键约束要求子表引用值必须始终存在于父表；修改主键导致原值消失而子表仍引用它，违反参照完整性。
不能直接修改被外键约束关联的父表主键值，否则会触发 UPDATE 或 DELETE 违反参照完整性约束的错误（如 MySQL 的 ERROR 1451 (HY000)，PostgreSQL 的 update or delete on table "xxx" violates foreign key constraint）。
为什么直接 UPDATE 主键会失败
外键约束默认要求子表中所有引用该主键的记录必须始终指向一个真实存在的父表行。一旦你尝试修改父表主键（比如把 id = 1 改成 id = 100），数据库会发现：原值 1 即将消失，而子表里还存着 parent_id = 1 —— 这就破坏了“子表值必须在父表存在”的规则。
常见错误现象包括：
- MySQL：
Cannot delete or update a parent row: a foreign key constraint fails - PostgreSQL：
update or delete on table "users" violates foreign key constraint "orders_user_id_fkey" on table "orders" - SQL Server：
The DELETE statement conflicted with the REFERENCE constraint
三种可行方案及其适用场景
核心思路只有两个：要么让子表先“松绑”，要么让新旧主键值在一段时间内共存。具体选哪种，取决于你的数据库类型、业务是否允许短暂不一致、以及是否有权限改约束。
-
方案一：临时禁用外键检查（仅限 MySQL）
SET FOREIGN_KEY_CHECKS = 0;→ 修改父表主键 →UPDATE子表外键字段 →SET FOREIGN_KEY_CHECKS = 1;⚠️ 风险高：跳过约束校验期间，可能写入非法数据；且不适用于 PostgreSQL / SQL Server -
方案二：级联更新（推荐，需建表时指定）
如果外键定义时用了
ON UPDATE CASCADE（如FOREIGN KEY (user_id) REFERENCES users(id) ON UPDATE CASCADE），那么执行UPDATE users SET id = 100 WHERE id = 1;会自动同步更新所有子表中的user_id。 ✅ 安全、原子、无需手动干预；❌ 要求建表时就规划好，运行时无法添加该行为 -
方案三：分步手动更新（通用，但需事务保护）
BEGIN TRANSACTION;→UPDATE子表外键字段为新值（如SET user_id = 100 WHERE user_id = 1）→UPDATE父表主键 →COMMIT;✅ 兼容所有数据库；✅ 可控性强；⚠️ 必须确保两步都在同一事务中，否则中间状态会违反约束
PostgreSQL 中的特殊处理：延迟约束
PostgreSQL 支持将外键设为 DEFERRABLE INITIALLY DEFERRED，这样约束检查会推迟到事务提交时才执行。你可以借此实现“先改父表、再改子表”的顺序：
ALTER TABLE orders
DROP CONSTRAINT orders_user_id_fkey,
ADD CONSTRAINT orders_user_id_fkey
FOREIGN KEY (user_id) REFERENCES users(id)
DEFERRABLE INITIALLY DEFERRED;
之后在事务中：
BEGIN;UPDATE users SET id = 100 WHERE id = 1;UPDATE orders SET user_id = 100 WHERE user_id = 1;-
COMMIT;← 此时才校验约束，因两步都完成，校验通过
注意：这需要你有 ALTER TABLE 权限，且不能用于已存在的数据冲突场景（比如新 id 已被其他行占用）。
最容易被忽略的细节
即使你用了 ON UPDATE CASCADE 或延迟约束，也要确认子表外键字段的数据类型和长度是否能容纳新主键值（比如把 TINYINT 主键改成 INT 值，但子表外键还是 TINYINT，就会截断或报错）。另外，主键被用作索引键时，大量更新可能引发锁等待或性能抖动——尤其是没加 WHERE 条件的全表主键更新，务必在低峰期操作并加好条件限制。
