不能直接update被外键约束的父表主键值，否则因违反参照完整性而报错；必须预先配置on update cascade，或采用事务内先更新子表再更新父表的分步方案。
UPDATE主键前必须确认外键ON UPDATE行为
直接执行 UPDATE SET id = ... 会失败或引发数据断裂，除非外键明确定义了 ON UPDATE CASCADE 或其他响应策略。MySQL 默认不允许多数主键更新操作——不是语法限制，而是外键约束在拦截。
常见错误现象：ERROR 1452 (HY000): Cannot add or update a child row: a foreign key constraint fails
- 检查外键定义：用
SHOW CREATE TABLE child_table查看是否含ON UPDATE CASCADE、SET NULL或RESTRICT -
RESTRICT（默认）会直接报错；NO ACTION行为等同于RESTRICT -
SET NULL要求子表外键列允许NULL，否则仍失败 - 若没定义任何
ON UPDATE，必须先DROP FOREIGN KEY，再改主键，最后重建外键（高风险，需停写）
用ON UPDATE CASCADE安全更新主键
这是唯一能“自动同步”的方式，但仅适用于业务允许级联且父表主键确实需要变更的场景（如迁移旧ID体系、合并租户ID）。
实操前提：
- 父表主键字段类型与子表外键字段**完全一致**（包括 signed/unsigned、长度、字符集）
- 子表外键列已建索引（否则
ON UPDATE CASCADE执行极慢甚至锁表） - 确保没有循环外键引用（A→B→A），否则
UPDATE会触发无限递归或报错
示例：修改 users 表主键并自动同步 orders 表
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id; ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON UPDATE CASCADE;
之后执行：UPDATE users SET id = 999 WHERE id = 100;，orders 中所有 user_id = 100 将自动变为 999。
没开CASCADE时的替代方案：分步+事务兜底
多数生产环境外键未启用 ON UPDATE CASCADE，因为主键变更本身应是低频、受控操作。此时必须人工保证一致性。
关键步骤（缺一不可）：
- 开启显式事务：
BEGIN; - 先更新子表外键值：
UPDATE orders SET user_id = 999 WHERE user_id = 100; - 再更新父表主键：
UPDATE users SET id = 999 WHERE id = 100; - 最后
COMMIT;；任一语句失败立即ROLLBACK;
注意：UPDATE 顺序不能颠倒——否则第二步会因外键约束失败。如果子表数据量大，建议加 WHERE 条件分批执行，并在 user_id 列上有索引。
为什么不该用REPLACE或DELETE+INSERT模拟主键更新
看似绕过约束，实则破坏参照完整性窗口期，极易出错。
典型陷阱：
-
REPLACE INTO users VALUES (999, ...)本质是DELETE + INSERT，期间 orders 表中user_id = 100的记录会短暂失去父记录，触发外键检查失败（除非禁用外键检查） - 手动
DELETE FROM users WHERE id = 100; INSERT ...同样存在空窗，且无法原子化 - 临时
SET FOREIGN_KEY_CHECKS = 0风险极高：一旦中途失败，子表残留无效外键，后续查询可能返回空或报错
真正安全的路径只有两条：走 ON UPDATE CASCADE，或严格按父子顺序+事务手动同步。其余都是掩耳盗铃。
主键更新不是常规操作，它暴露的是ID设计缺陷。优先考虑用业务键（如 tenant_id + code）替代数字主键做关联，把主键留给数据库内部管理——这才是多数团队最终收敛的方向。
