在执行 INSERT INTO VALUES 的时候，不管插入多少行，都只申请一次主键，一次申请够，这些主键必然是连续的。所以你可以从返回的最后一个 ID 推测出全部 ID

• innodb_autoinc_lock_mode的值，这回影响主键生成策略，在数据迁移的时候需要考虑处理主键问题
• 公司的binlog模式，在后面增量校验和修复数据里面使用的是行模式的binlog
• 公司是否有统一的数据库规范，比如必须要更新时间戳、不能硬删除，只能软删除
• 使用的ORM框架怎么实现双写
• 公司是否做过数据迁移？如果做过，具体的方案是什么

重构系统：

这个系统是我们公司的一个核心系统，但是又有非常悠久的历史。在我刚接手的时候，它已经处于无法维护的边缘了。但是不管是重构这个系统，还是重新写一个类似的系统，已有的数据都是不能丢的。所以我的核心任务就是重新设计表结构，并且完成数据迁移。为此我设计了一个高效、稳定的数据迁移方案。

实际落地了单库拆分 分库分表

进公司的时候，刚好遇上单库拆分分库分表。我主要负责的事情就是设计一个数据迁移方案，把数据从单库迁移到分库分表上。

数据迁移方案的基本步骤：

1. 创建目标表
2. 用源表数据初始化目标表
3. 执行一次校验，并修复数据，此时用源表数据修复目标表数据
4. 业务代码开启双写，读源表，并且先写源表，数据以源表为主
5. 开启增量校验和数据修复，保持一段时间
6. 切换双写顺序，此时读目标表，并且先写目标表，数据以目标表为准
7. 继续保持增量校验和数据修复
8. 切换为目标表单写，读写都只操作目标表

不考虑数据校验的话，整个数据迁移过程是这样的

图右边的两步都要考虑校验和修复数据的问题