不能直接update被外键约束的父表主键，否则违反参照完整性并报错；必须通过临时禁用外键检查、分步手动更新（先子表后父表）或预先定义on update cascade（仅mysql支持）来实现。
直接执行 UPDATE 会报错：Cannot update or delete a parent row
当你尝试 UPDATE 或 DELETE 一个被其他表通过 ON DELETE CASCADE 外键引用的父表记录时，MySQL/PostgreSQL 通常不会阻止——但如果你改的是主键或唯一键（比如把 id = 1 改成 id = 100），就会触发约束检查失败，报错类似：Cannot update or delete a parent row: a foreign key constraint fails。这不是级联删除在起作用，而是数据库在阻止你破坏引用完整性。
- 级联删除只响应
DELETE，不响应UPDATE主键值 - 想批量改父表主键？必须先禁用外键检查，或重写为“复制+删除”逻辑
- PostgreSQL 更严格：即使关了
SET CONSTRAINTS ALL DEFERRED，更新主键仍被禁止，必须用ALTER TABLE ... DROP CONSTRAINT临时移除外键
安全批量修改的两种实操路径
核心思路只有两个：要么绕过约束校验，要么让子表同步适配变更。选哪个取决于你是否允许短暂的数据不一致、是否有权限操作 DDL。
-
路径一（推荐，适用于 MySQL）：临时关闭外键检查
SET FOREIGN_KEY_CHECKS = 0;
执行你的UPDATE parent_table SET id = new_id WHERE ...
再手动同步子表：UPDATE child_table SET parent_id = new_id WHERE parent_id = old_idSET FOREIGN_KEY_CHECKS = 1; -
路径二（通用，但需 DDL 权限）：临时删除外键，改完再重建
ALTER TABLE child_table DROP FOREIGN KEY fk_name;
执行父表UPDATE
执行子表UPDATE（必须做，否则重建外键会失败）ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON DELETE CASCADE;
UPDATE 主键后子表没自动更新？不是 BUG，是设计如此
ON DELETE CASCADE 是单向动作：它只定义“删父行时自动删子行”，不提供“改父主键时自动改子外键”的能力。这是 SQL 标准行为，所有主流数据库都一样。别指望加个 ON UPDATE CASCADE 就万事大吉——虽然 MySQL 支持它，但 PostgreSQL 默认不支持（需用触发器模拟），而且一旦启用，批量更新主键可能意外拖垮子表索引性能。
CAD通信网关公共库（装修设计扩展版）。提供统一CAD COM封装接口，支持AutoCAD/天正双模式，包含装修专业图层体系、材料图块、房间边界检测、弧形吊顶COM接口。复用建筑施工图方案Skill0公共库。
- MySQL 中可显式声明：
FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON UPDATE CASCADE - 但上线前务必压测：一次更新 10 万父记录，可能触发 10 万×N 次子表索引更新
- 生产环境更稳妥的做法是：用应用层分批处理 + 子表
UPDATE+ 事务包裹，比依赖ON UPDATE CASCADE更可控
真正要小心的其实是 WHERE 条件漏写或匹配错误
批量 UPDATE 最常翻车的地方，从来不是约束本身，而是 WHERE 写错导致全表误更新。尤其当父表和子表都有相似字段名（比如都叫 status）时，容易手滑写成 UPDATE parent_table SET id = ... WHERE status = 'active'，结果把几百条不该动的记录全改了。
- 执行前一定先用
SELECT COUNT(*) FROM parent_table WHERE ...确认影响行数 - 涉及多表联动时，优先用子查询而非 JOIN 更新（MySQL 不支持
UPDATE ... JOIN直接改父表主键） - 在测试库跑通后，把语句存成带注释的脚本，例如：
-- 修改用户ID 1001→2001，同步更新订单表 user_id 字段，2024-06-15 by dev
级联约束本身不增加修改难度，难的是确保每一步变更都被显式控制。只要主键更新逻辑和子表同步节奏对得上，就没必要回避批量操作。
