Auto Increment在数据迁移时需要注意什么

在数据迁移（Data Migration）中，AUTO_INCREMENT（自增）字段是最容易出问题的点之一，核心风险是主键冲突、数据错乱、业务中断。下面从常见场景、注意事项、最佳实践三个层面系统说明。

一、为什么 AUTO_INCREMENT 在迁移中容易出问题？

AUTO_INCREMENT 的本质是：

数据库内部维护一个计数器，插入时自动生成唯一值

在迁移过程中，源库和目标库的自增状态往往不一致，一旦处理不当，会引发严重问题。

二、常见迁移场景与风险

1️⃣ 全量迁移（一次性）

风险点

• 目标表 AUTO_INCREMENT 值 < 已导入数据的最大 ID
• 插入新数据时直接 主键冲突（Duplicate entry）

✅ 表现：

ERROR 1062: Duplicate entry '12345' for key 'PRIMARY'

2️⃣ 增量迁移（新老系统并行）

风险点

• 新老库同时写数据
• 自增 ID 重复
• 数据合并时无法区分来源

✅ 典型后果：

• 订单、用户、日志 ID 冲突
• 业务数据被覆盖或错乱

3️⃣ 分库分表 / 合并表

风险点

• 多个表合并到一个表
• 各自的自增 ID 范围重叠

4️⃣ 主从切换 / 云迁移

风险点

• 主从自增计数器不同步
• 切换后插入失败

三、迁移时必须注意的关键点 ✅

✅ 1. 迁移前：确认当前 AUTO_INCREMENT 值

SHOW CREATE TABLE your_table;
-- 或
SELECT AUTO_INCREMENT
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'db_name'
  AND TABLE_NAME = 'your_table';

✅ 2. 迁移后：手动修正 AUTO_INCREMENT

原则：

目标表 AUTO_INCREMENT ≥ 当前最大 ID + 1

ALTER TABLE your_table AUTO_INCREMENT = 100000;

⚠️ 注意：

• MySQL 中 只能调大，不能调小
• InnoDB 重启后可能重新计算（MySQL 8.0 有持久化机制）

✅ 3. 全量迁移时：先导入数据，再建自增

推荐顺序：

-- 1. 建表（无 AUTO_INCREMENT）
-- 2. 导入数据
-- 3. 修改表结构
ALTER TABLE your_table MODIFY id BIGINT AUTO_INCREMENT;
ALTER TABLE your_table AUTO_INCREMENT = 新值;

✅ 好处：避免导入时自增冲突

✅ 4. 新老系统并行：避免自增 ID 冲突

✅ 方案 1：ID 分段（最常用）

ALTER TABLE orders AUTO_INCREMENT = 1000000;

✅ 方案 2：使用 BIGINT + 步长（分库）

auto_increment_increment = 2
auto_increment_offset = 1 / 2

⚠️ 仅适合分库，不适合迁移

✅ 方案 3：放弃自增，使用全局 ID（推荐）

• Snowflake
• UUID
• 发号器（Leaf / TinyID）

✅ 迁移友好、扩展性强

✅ 5. 不要依赖 AUTO_INCREMENT 做业务含义

❌ 错误用法：

• 订单号
• 流水号
• 业务唯一标识

✅ 正确做法：

• 自增 ID 只做主键
• 业务号单独生成

✅ 6. 注意不同数据库的行为差异

四、迁移检查清单 ✅

✅ 是否确认源库最大 ID
✅ 是否确认目标库 AUTO_INCREMENT
✅ 是否处理新老系统并行写入
✅ 是否有业务依赖自增 ID
✅ 是否测试过插入新数据
✅ 是否备份并验证数据一致性

五、一句话总结

AUTO_INCREMENT 迁移的核心原则：
保证“下一个自增值”一定大于已有数据的最大 ID，
并尽量避免新老系统同时生成自增 ID。

如果你愿意，我可以：

• 针对 MySQL / PostgreSQL / Oracle 给具体迁移 SQL
• 帮你设计 新老系统并行迁移方案
• 分析你当前表结构是否“迁移安全”