我要评论mysql 批量随机化主键 id，如何同步更新关联子表？
在开发过程中，有时候会遇到一个需求：把一张表的主键 id 全部替换成随机数，同时保证关联子表中的外键字段也能同步更新。
比如我们有两个表：
| 表名 | 作用 |
|---|---|
table_info | 记录表信息，主键是 id |
field_info | 记录字段信息，里面有 table_id 关联 table_info.id |
现在要把 table_info.id 改成随机数，同时 field_info.table_id 也要跟着一起改。
如果直接改主表 id，子表关联关系就会断掉；如果两张表分别随机生成，又无法保证对应关系一致。
所以核心思路是：先生成旧 id 和新 id 的映射关系，再按照映射关系统一更新两张表。
为什么不能直接随机更新？
假设直接这样写：
update table_info set id = floor(rand() * 9000000) + 1000000;
这样虽然主表 id 变了，但 field_info.table_id 还是旧 id，关联关系就乱了。
如果两张表分别随机生成新 id，也会出现一个问题：
主表生成的新 id 和子表生成的新 id 不是同一组，无法对应。
所以不能分开随机，必须提前确定好：
旧 id -> 新 id
这个映射关系确定之后，两张表都按照这个映射去更新，才能保证数据一致。
推荐方案：临时映射表 + 事务更新
整体流程分为四步：
- 创建临时映射表
- 生成旧 id 和新 id 的映射关系
- 在事务中先更新子表，再更新主表
- 确认无误后提交，出错则回滚
第一步：创建临时映射表
先建一个临时表，用来保存旧 id 和新 id 的对应关系。
create temporary table id_mapping (
old_id int,
new_id int,
primary key (old_id),
unique key (new_id)
);
这里有两个关键点：
| 约束 | 作用 |
|---|---|
primary key (old_id) | 保证每个旧 id 只对应一个新 id |
unique key (new_id) | 防止随机生成重复的新 id |
加上 unique key (new_id) 很重要，因为随机数可能会碰撞。如果生成重复值，插入时就会直接报错，避免后面出现主键冲突问题。
第二步：生成映射关系
把 table_info 中的每个旧 id 都生成一个随机新 id，并写入临时表。
insert into id_mapping (old_id, new_id) select id, floor(rand() * 9000000) + 1000000 from table_info;
这里的随机范围是：
floor(rand() * 9000000) + 1000000
也就是生成 1000000 ~ 9999999 之间的随机整数。
如果数据量比较小，这个范围通常够用。如果数据量很大，建议进一步扩大范围，降低碰撞概率。
执行完成后，可以查询一下映射结果：
select * from id_mapping;
确认每个旧 id 都正确对应了一个新 id，再进行下一步。
第三步：在事务中更新两张表
确认映射关系没问题后，进入事务处理。
begin;
1. 先更新子表
先更新 field_info 中的 table_id。
update field_info f join id_mapping m on f.table_id = m.old_id set f.table_id = m.new_id;
这一步的作用是：
把 field_info 中所有旧的 table_id，替换成映射表中的新 id
2. 再更新主表
然后更新 table_info 的主键 id。
update table_info t join id_mapping m on t.id = m.old_id set t.id = m.new_id;
这一步的作用是：
把 table_info 中的旧 id，替换成映射表中的新 id
为什么必须先更新子表？
如果两张表之间存在外键约束，更新顺序非常重要。
正确顺序是：
先更新子表 field_info 再更新主表 table_info
如果反过来，先更新主表 id，子表中的 table_id 还指向旧 id，就可能触发外键约束报错。
所以安全顺序是：
子表先改外键 -> 主表再改主键
如果没有外键约束，顺序影响相对小一些，但仍然建议按照这个顺序执行，逻辑更清晰。
第四步：提交或回滚
如果执行过程中没有问题，可以提交事务：
commit;
如果发现映射关系有问题，或者更新结果不符合预期，可以回滚：
rollback;
回滚后，两张表的数据都会恢复到更新前的状态。
最后可以清理临时表：
drop temporary table id_mapping;
如果是在同一个会话中完成全部操作，临时表会在会话结束时自动删除。
完整 sql 流程
完整流程可以整理成下面这样：
-- 1. 创建临时映射表
create temporary table id_mapping (
old_id int,
new_id int,
primary key (old_id),
unique key (new_id)
);
-- 2. 生成旧 id 和新 id 的映射关系
insert into id_mapping (old_id, new_id)
select id, floor(rand() * 9000000) + 1000000
from table_info;
-- 3. 检查映射关系
select * from id_mapping;
-- 4. 开启事务
begin;
-- 5. 先更新子表
update field_info f
join id_mapping m on f.table_id = m.old_id
set f.table_id = m.new_id;
-- 6. 再更新主表
update table_info t
join id_mapping m on t.id = m.old_id
set t.id = m.new_id;
-- 7. 确认无误后提交
commit;
-- 8. 清理临时表
drop temporary table id_mapping;
操作前需要注意的几点
1. 先备份数据
修改主键是高风险操作，建议提前备份相关表数据。
尤其是生产环境，不要直接执行。
2. 先在测试环境验证
建议先在测试库中跑一遍，确认：
- 映射关系正确
- 子表关联字段同步成功
- 主表主键更新成功
- 没有数据丢失或重复
3. 注意随机数碰撞
rand() 生成的随机数可能会重复。
如果数据量较大，建议扩大随机范围，例如：
floor(rand() * 90000000) + 10000000
同时在临时表中加上：
unique key (new_id)
这样一旦生成重复新 id，就会提前报错，而不是等到更新主键时才发现冲突。
4. 数据量大时注意性能
如果数据量很大，一次性 update 可能会比较慢，甚至影响线上业务。
这种情况下可以考虑：
- 分批更新
- 在低峰期执行
- 给关联字段加索引
- 避免长时间锁表
例如 field_info.table_id 最好有索引：
alter table field_info add index idx_table_id (table_id);
这样 join 更新时效率会更高。
另一种思路：外键级联更新
如果两张表之间已经建立了外键关系，也可以使用外键级联更新。
例如：
alter table field_info add constraint fk_field_table_id foreign key (table_id) references table_info(id) on update cascade;
配置之后，只要更新 table_info.id，field_info.table_id 会自动同步更新。
但这种方式有几个前提：
- 主表主键字段和子表外键字段类型必须一致
- 子表外键字段建议有索引
- 不能存在循环外键依赖
- 很多项目实际并不使用外键约束
所以如果没有外键约束，还是推荐使用临时映射表方案，更通用，也更可控。
总结
批量随机化主键 id 的关键不是“怎么生成随机数”，而是：
如何保证主表和子表使用同一套新 id。
所以最稳妥的做法是：
- 用临时表保存旧 id 和新 id 的映射关系
- 给新 id 加唯一约束，防止随机碰撞
- 在事务中先更新子表，再更新主表
- 确认无误后提交，有问题及时回滚
这样做的好处是：
- 主表和子表同步一致
- 操作过程可检查
- 出错可以回滚
- 不会破坏原有业务关联关系
如果你也有类似“主键 id 需要随机化，但子表外键需要同步更新”的场景，可以按这个思路处理。
以上就是mysql批量随机化主键id并同步更新关联子表的方法的详细内容，更多关于mysql随机化主键id并同步更新表的资料请关注代码网其它相关文章！
发表评论