迁移到分库分表方式
一般来说，会有三种方式：
- 1、停止部署法。
- 2、双写部署法，基于业务层。
- 3、双写部署法，基于 binlog 。
具体的详细方案，可以看看如下两篇文章：
分库分表后数据迁移问题
- 双写 以老库为主。读操作还是读老库老表，写操作是双写到新老表。
- 历史数据迁移 dts + 新数据对账校验（job） + 历史数据校验。
- 切读：读写以新表为主，新表成功就成功了。
- 观察几天 下掉写老库操作。
实践
1. 双写。 以老库为主，都读写老库。双写开关：监听binlog，写新库。(insert数据大概率成功，update数据大概率失败。
失败后，写入redis，后续定时任务，读老库数据再补偿到新库。ps：补偿时，如果新库有，说明要修改新库数据；如果新库没有，说明要插入数据到新库)
2. 数据迁移。 将老库数据迁移到新库。为了防止高峰时对DB压力过大。晚上1点到6点才做迁移工作。记录下迁移的进度，比如已经迁移的主键ID。定时任务去做。
注意：迁移的时候，比如100条数据插库。插入前，先校验100条数据的ID是否存在，如果存在，就去除存在的数据，插入不存在的数据。如果后续老库数据有修改，也会触发binlog来写到新库的。
3. 如果要更精准，可以做数据校验。
4. 切新库读写，观察。出问题，立刻切换到老库。
分布式事务解决
目前市面上，分布式事务的解决方案还是蛮多的，但是都是基于一个前提，需要保证本地事务。那么，就对我们在分库分表时，就有相应的要求：数据在分库分表时，需要保证一个逻辑中，能够形成本地事务。举个例子，创建订单时，我们会插入订单表和订单明细表，那么：
- 如果我们基于这两个表的 id 进行分库分表，将会导致插入的记录被分到不同的库表中，因为创建下单可以购买 n 个商品，那么就会有 1 条订单记录和 n 条 订单明细记录。而这 n 条订单明细记录无法和 1 条订单记录分到一个库表中。
-
如果我们基于这两个表的 user_id 进行分库分表，那么插入的记录被分到相同的库表中。