根本原因是数据库执行UPDATE主键时立即检查参照完整性，发现子表外键引用即将失效的旧值而报错；ON UPDATE CASCADE可自动同步更新子表，或用事务先改子表再改父表，二者均需外键列有索引。
UPDATE 主键直接报错的根本原因
不是语法写错了，是数据库在执行时立刻检查参照完整性：父表主键值一改，原值就没了，但子表里还存着旧外键值，比如 user_id = 1。数据库发现“子表引用了一个即将不存在的值”，立刻拒绝——MySQL 报 ERROR 1451 (HY000)，PostgreSQL 报 update or delete on table "users" violates foreign key constraint，SQL Server 报 The UPDATE statement conflicted with the REFERENCE constraint。
ON UPDATE CASCADE 是最干净的解法（但得建表时就留好）
如果外键定义里带了 ON UPDATE CASCADE，比如：
ALTER TABLE orders ADD CONSTRAINT fk_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，一步到位、事务安全、无需手动干预。
- ✅ 优点：原子性保障，无中间不一致状态
- ❌ 缺点：运行时无法给已有外键追加该行为；MySQL/PostgreSQL/SQL Server 都支持，但必须建表或加约束时显式声明
- ⚠️ 注意：某些 ORM 或迁移工具生成的外键默认不带级联，别假设它存在
没有级联？那就用事务分步更新（通用但需严格顺序）
核心是让子表先“对齐”新值，再动父表主键，全程包在事务里：
BEGIN TRANSACTION; UPDATE orders SET user_id = 100 WHERE user_id = 1; UPDATE users SET id = 100 WHERE id = 1; COMMIT;
- ✅ 兼容所有数据库（MySQL、PostgreSQL、SQL Server）
- ⚠️ 必须确保两步都在同一事务中，漏掉
COMMIT或中间出错未ROLLBACK，会导致子表出现指向不存在主键的脏数据 - ⚠️ 如果子表数据量大，
UPDATE orders可能锁表或变慢，建议提前加索引（如CREATE INDEX idx_orders_user_id ON orders(user_id);）
MySQL 临时关外键检查？危险，仅限紧急救火
SET FOREIGN_KEY_CHECKS = 0; 确实能绕过校验，但代价极高：
- ❌ 关闭期间任何非法插入（比如往
orders插个user_id = 999）都不会被拦住 - ❌ 不适用于 PostgreSQL / SQL Server（它们不提供等效开关）
- ⚠️ 即使你只用它改一条记录，也必须配对执行
SET FOREIGN_KEY_CHECKS = 1;，且之后要人工验证数据一致性
真正需要它的时候极少——比如修复一张因误操作已损坏的测试库，而不是日常运维手段。
最容易被忽略的一点：级联更新和分步更新都依赖外键列上有索引。没索引时，子表 UPDATE 可能全表扫描，卡住整个业务；而索引缺失本身又常被当成“小问题”拖着不处理。
