数据库迁移UUID冲突怎么办

数据库迁移时出现 UUID 冲突（通常是主键或唯一标识冲突），一般可以从“事前避免”和“事后处理”两个维度来解决。下面按常见场景给你一套思路。

一、先确认冲突来源

UUID 冲突常见原因：

1. 老系统用自增 ID，新系统用 UUID，迁移时手动生成 UUID 重复
2. 多数据源 / 多库合并，各自生成 UUID 撞车
3. 测试数据 / 种子数据 写死 UUID
4. 应用层生成 UUID 不规范（如用随机而非标准算法）
5. 历史数据 UUID 本身就有重复（脏数据）

二、事前避免（推荐）

1. 使用标准 UUID 生成方式

• ✅ UUID v4（随机）
• ✅ UUID v7（时间有序，推荐新系统）
• ❌ 自己拼字符串当 UUID

2. 迁移前做唯一性校验

SELECT uuid, COUNT(*)
FROM table
GROUP BY uuid
HAVING COUNT(*) > 1;

3. 多库合并时加“命名空间”

例如：

• 库 A：a-xxxx-xxxx
• 库 B：b-xxxx-xxxx 或使用 UUID v5（基于命名空间）

三、冲突已经发生怎么办？

方案 1：重新生成 UUID（最常用）

前提：UUID 不是对外暴露的业务标识

UPDATE table
SET id = gen_random_uuid()
WHERE id IN (
  SELECT id FROM table
  GROUP BY id
  HAVING COUNT(*) > 1
);

⚠️ 注意：

• 先处理 外键依赖
• 建议在事务中执行

方案 2：保留旧 UUID，新增“迁移 UUID”

适合：

• UUID 已对外（API / 日志 / 第三方）

表结构：

id UUID PRIMARY KEY
legacy_id UUID

查询时兼容旧值。

方案 3：分库分表前缀法

例如：

user_01_xxxx-xxxx
user_02_xxxx-xxxx

方案 4：临时关闭约束 → 修复 → 开启

ALTER TABLE t DISABLE TRIGGER ALL;
-- 修复数据
ALTER TABLE t ENABLE TRIGGER ALL;

⚠️ 仅限维护窗口

四、ORM / 框架注意点

• Hibernate：@GeneratedValue 别混用
• MyBatis：别在代码里手写 UUID
• 迁移脚本：禁止硬编码 UUID

五、最佳实践总结

✅ 新系统统一用 UUID v7
✅ 迁移脚本自动生成，不人工指定
✅ 迁移前后做 唯一性校验
✅ 外键关系提前梳理

如果你愿意，可以告诉我：

• 用的什么数据库（PostgreSQL / MySQL / Oracle）
• UUID 是否对外暴露
• 是单库迁移还是多库合并

我可以给你具体可执行的 SQL / 脚本。