1：项目背景
“ 本文正在参加「金石计划」 ”，在新的项目中，有一个上传数据的功能，数据都是Excel格式的，前期的业务比较少，所以单表存储这些数据并没有什么压力，后面发现有些Excel都是几万，几万的数据，导致二个多月以后，数据已经到达了500多万了，项目才上线半年不到，主要这些数据还是提供了查询功能，如果继续使用单表，那么总有一天会因为数据量太大导致查询效率低下，所以这时候想到了分表处理。
2：单表到多表的演变
经过评审，我们最终决定使用Sharding-jdbc来实现分表。但是这时候就遇到一个问题，如何将老数据迁移到新的表中。一般来说会有二种方案
停服处理
也就是将告诉客户，系统正在升级，让客户过段时间再访问，然后我们在进行数据的迁移，这种方案会简单很多，缺点就是系统有一段时间无法使用
不停服处理
在数据迁移过程中，用户是无感知的，我们在进行数据迁移的过程中，系统可以正常访问，缺点就是方案更加复杂
经过商讨，我们最终选用停服处理
3：迁移方案
整体的实现流程如下
4：迁移过程中需要考虑的问题
1：数据是一次性导入还是批量
我们的数据是一次性将全部数据迁移还是分批次迁移。我建议是使用分批次迁移，一次性迁移数据量太大，可能内存不足。
2：某个批次导入失败，怎么知道是哪个批次的数据导入失败了
既然我们是使用分批次导入，那么其中有一个批次的数据导入失败了怎么办，我们又是怎么知道那个批次导入失败了。所以这时候我们会有一张迁移记录表，改表记录了迁移的批次，数据的范围，同步状态等一些信息，后续可以查看这张表，如果有某个批次数据迁移失败，只需再次同步这一次批次的数据即可，这也是为什么我们要使用分批次导入数据的原因，如果你是一次性迁移全部数据，那么如果中途失败了，那么又要重新迁移，浪费资源又浪费时间
3：批量多次导入，如果中途某一个批次导入失败，怎么办
如果某个批次导入失败了，那么我们就重新导入就行了。
4：导入失败之后重新导入，有重复数据怎么办
某个批次导入失败，我们就会重新导入，这个时候新表中可能已经存在这条数据了，所以我们要做好数据校验，已经有的数据就不需要再次导入了
5：怎么校验数据全部导进去了
这个也是最重要的，我们要检验数据的准确性，是否有多导入的数据，或者少导入了数据
6：验证线上分库分表逻辑
这个就是在将数据从单表迁移到多表之后，我们要验证线上服务是否正常，数据是否正常
5：总结
停服处理相对来说还是会简单些，之所以采用这种方案也是因为简单，只需要在数据迁移完成之后验证数据准确就可以了
