MySQL 亿级数据平滑迁移实战（来自vivo）
https://www.cnblogs.com/vivotech/p/18373623
1、方案选型
常见的迁移方案大致可以分为以下几类：
而预约业务有以下特点：
- 读写场景多，频率高，在用户预约/取消预约/福利发放等场景均涉及到大量的读写。
- 不可接受停机，停机不可避免的会造成经济损失，在有其他方案的情况下不适合选择此方案。
- 大部分的场景能接受秒级的数据不一致，少部分不能。
结合这些特点，我们再评估下上面的方案：
停机迁移方案需要停机，不适用于预约场景。
预约场景存在不活跃的用户数据，如果用渐进式迁移方案的话很难迁移干净，可能还需要再写一个迁移任务来辅助完成迁移。
双写方案最大的优势在于每一步操作都可向上回滚，能尽可能的保证业务不出问题。
因此，最终选择的是双写方案。预约业务涉及到的读写场景多，每一个场景单独进行改造的成本大，采用 Mybatis 插件来实现迁移所需的双写等功能，可以有效降低改造成本。
2、前期准备
// 全量同步基于 MySQLDump 实现；增量同步基于 binlog 实现；一致性校验通过在新老库各选一个分块，然后聚合列数据计算并对比其特征值实现。
