UPDATE父表主键必失败，因外键要求子表引用值实时存在；ON UPDATE CASCADE是最优解但需建表时定义；通用方案是事务内先更新子表外键再更新父表主键。
不能直接 UPDATE 含外键的主键值，否则必然报错；安全更新必须绕过“原值消失而子表仍引用”的完整性冲突。
为什么 UPDATE parent_table SET id = 100 WHERE id = 1 一定失败
外键约束要求：子表中每个 parent_id 值，必须在父表 id 中实时存在。执行该语句时，数据库会在写入前检查——原值 1 即将被覆盖，而子表里还有 parent_id = 1 的行，违反参照完整性。典型错误包括：
- MySQL：
ERROR 1451 (HY000): Cannot delete or update a parent row - PostgreSQL：
update or delete on table "users" violates foreign key constraint "orders_user_id_fkey" - SQL Server：
The UPDATE statement conflicted with the REFERENCE constraint
用 ON UPDATE CASCADE 是最干净的解法（但需建表时预留）
如果外键定义时已声明 ON UPDATE CASCADE，后续主键更新会自动同步子表，全程原子、无手动干预：
ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON UPDATE CASCADE;
之后执行：
UPDATE users SET id = 100 WHERE id = 1;
→ orders 表中所有 user_id = 1 的行会自动变成 100。
⚠️ 注意：运行时无法给已有外键追加 ON UPDATE CASCADE，必须先 DROP FOREIGN KEY 再 ADD 新约束（且 MySQL 不允许对已存在数据的列直接加级联，可能需先清空子表或临时禁用检查）。
通用方案：事务内分步更新（BEGIN; UPDATE child; UPDATE parent; COMMIT;）
适用于所有数据库，但顺序和事务边界必须严格：
- 先
UPDATE子表外键字段（如SET user_id = 100 WHERE user_id = 1），把旧引用转为新值 - 再
UPDATE父表主键（如SET id = 100 WHERE id = 1） - 两步必须包裹在同一个
BEGIN TRANSACTION/COMMIT中，否则中间状态会触发约束失败 - PostgreSQL 可配合
DEFERRABLE INITIALLY DEFERRED外键，允许颠倒顺序（先改父表，再改子表），但需建表时定义，运行时不可改
MySQL 临时禁用外键检查（仅限紧急修复，不推荐生产）
仅 MySQL 支持，其他数据库（PostgreSQL/SQL Server）无等效机制：
SET FOREIGN_KEY_CHECKS = 0; UPDATE users SET id = 100 WHERE id = 1; UPDATE orders SET user_id = 100 WHERE user_id = 1; SET FOREIGN_KEY_CHECKS = 1;
⚠️ 风险极高：禁用期间任何非法写入（如插入不存在的 user_id）都不会被拦截，且一旦忘记恢复，后续所有 DML 都失去外键保护。绝不应在高并发或多人协作环境使用。
真正容易被忽略的是：外键行为不是“开关”，而是建表时就固化的设计决策。想支持主键更新，必须在最初定义外键时就选好 ON UPDATE 策略，或者接受事务分步更新带来的业务逻辑侵入。
