主要观点总结
文章描述了一次数据表迁移的过程，从背景、方案选型、前期准备、双写流程、总结等方面详细阐述了迁移过程中的关键步骤和注意事项。
关键观点总结
关键观点1: 背景
由于历史原因，预约业务数据表与其他业务数据表存储在同一个数据库中，可能影响系统稳定性和数据隔离性。为了提高系统稳定性和数据隔离性，需要将预约相关数据表迁移到一个独立的数据库中。
关键观点2: 方案选型
常见的迁移方案可以分为几类，结合预约业务的特性（读写场景多、频率高、不可停机、大部分场景能接受秒级数据不一致等），最终选择双写方案。
关键观点3: 前期准备
包括全量同步、增量同步、一致性校验和代码改造等步骤，其中涉及到数据同步工具、Mybatis的BeanNameGenerator、主键id的处理、Mybatis插件的实现等。
关键观点4: 双写流程
描述了从上线双写改造后的业务代码、同步老库数据到新库、停止同步工具并切换双写、开启对比和补偿程序、逐步切量请求到新库、停止对比补偿任务、读写都切换到新库等步骤，以及在此过程中需要注意的问题，如自增主键、事务、异步写入等。
关键观点5: 总结
对数据表迁移过程中遇到的问题和解决方案进行了总结，并给出了对类似迁移任务的建议。
文章预览
一、背景 预约业务是 vivo 游戏中心的重要业务之一。由于历史原因，预约业务数据表与其他业务数据表存储在同一个数据库中。当其他业务出现慢 SQL 等异常情况时，可能会直接影响到预约业务，从而降低系统整体的可靠性和稳定性。为了尽可能提高系统的稳定性和数据隔离性，我们迫切需要将预约相关数据表从原来的数据库中迁移出来，单独建立一个预约业务的数据库。 二、方案选型 常见的迁移方案大致可以分为以下几类： 而预约业务有以下特点： 读写场景多，频率高，在用户预约/取消预约/福利发放等场景均涉及到大量的读写。 不可接受停机，停机不可避免的会造成经济损失，在有其他方案的情况下不适合选择此方案。 大部分的场景能接受秒级的数据不一致，少部分不能。 结合这些特点，我们再评估下上面的方案： 停机迁移方案需要停机
………………………………
