上篇我们讲了单库分表在新业务上的实践，相对比较简单，这篇我们接着聊。单库分表-老业务老业务就是原先表设计好了且业务已经在线跑了一段时间了，有历史数据了。那么就有数据迁移的问题。迁移方向是从单表的老表到多表的新表。在表结构不变的情况下要注意几个问题：主键id问题数据迁移主键id问题老表主键很可能是自增的，新表是分布式id,很可能是用雪花算法计算出来的，是不一样的。首先要保证新表的id和老表的不重复，当然这个重复的概率比较小。老表id根据情况迁移到新表后可以用原始id值，也可以重新生成新的id。如果你的业务并没有用老表id作任何业务操作只是一个主键标识，那么无所谓改不改，如果为了统一也可以重新用算法生成新的id。而如果老表id本身有参与业务，比如你的SQL里面有利用这个字段关联表，那么就不要动了，因为成本非常高，改的东西很多，个人认为没有必要。数据迁移数据迁移或者叫在线扩容，我们这里的场景只针对之前是单库单表变成单库多表的情况。停机迁移当然是可以的，停机后将老表数据同步分流到新表上，然后再开机，这样数据不会有不一致的问题。但是要看业务情况，很多业务是7*24小时在线不允许停机的，那就不能进行停机迁移，而如果允许一段时间停机比如某政务系统，给系统用户发个通告停机一段时间，是可以的。至于具体数据迁移操作可以借用工具或者自己编写程序做，根据不同方法的性能和影响时间进行选择，我们当然期望停机时间越短越好。不停机迁移常见的方式是双写，将业务数据双写到老表和新表中，这样能保证从双写开始时点的新数据是一致的，至于老数据再通过程序或工具慢慢迁移，直到迁移完成新老表中的数据一致就可以将应用程序完全切换到新的分表进行操作，停掉对于老表的访问。ShardingSphere提供的迁移工具上文中有关数据迁移的方案无论是停机还是不停机的都跟ShardingSphere没有关系，这里我们看一下ShardingSphere提供的方案，或者说利用ShardingSphere我们如何做好数据迁移。Sharding-Proxy+Sharding-Scaling是专门用于设计处理分库分表扩容数据迁移问题的组件我们先抛开别的不谈，先针对数据迁移这个动作来说具体针对本文的例子来说就是把一张单表的数据迁移到具有分表规则的多表中。想一下，其实原理比较简单：就是从单表中把数据读出来然后根据分表规则insert到新表中。来看下用ShardingSphere-proxy结合ShardingSphere-Scaling怎么做。软件版本情况：MySQL8.0ShardingSphere-proxy5.0-betaShardingSphere-Scaling5.0-betaShardingSphere-proxy这端比较简单，跟之前文章中介绍的proxy配置方法差不多，下文是我的config-myapp.yaml的配置：schemaName:my-app
dataSources:write_ds:url:jdbc:mysql://mysql.local.test.myapp.