前面发过一篇分库分表的文章，展示了批量变更分库分表的方法（详见《如何通过一条 SQL 变更多个分库分表》），这次我们再来聊另一个分库分表相关的话题：如何迁移多个分库分表的数据到其他分库分表，或者将多个分库分表聚合到一个表中。

对于实行分库分表的企业来说，这应该算是刚需，为什么是刚需？我来举几个实际场景的例子。

• 业务持续增长，初期分库分表方案难以满足需求

虽然已经做了分库分表了，但也架不住持续增加的数据量啊，导致的问题就是现有分库分表策略已经满足不了存储和性能需求了，那就只能进一步扩展分库分表的数量。怎么扩展呢？重新规划新的分库分表策略，然后把原来的数据迁移到新的分库分表中。

• 分片策略调整（Re-Sharding）

最初的分库分表策略是按照买家 ID 进行分片的，但随着业务的深入，发现用卖家 ID 进行分片更加合适，这种情况下，需要先重新调整分片逻辑，再将原来的数据迁移到新的分库分表中。

上述场景都是比较常见的分库分表迁移需求，虽说是刚需，支持这种场景的好用的工具却不多，主要原因在于分库分表的复杂性涉及数据分片、业务逻辑、数据一致性等多方面问题。

在这里提供一个简单且实用的方法，用 NineData 的库表分组功能结合其强大的数据复制功能，轻松解决上述问题。

我们先来看一下 NineData 解决该问题的流程。

直接开整

1. 创建库表分组：根据业务的分库分表逻辑创建库表分组。

源库的分库分表配置。

目标库的分库分表配置。

2. 创建数据复制任务：创建数据复制任务，源和目标分别选择上面创建的库表分组即可 。

3. 查看迁移结果：任务跑完后，可以查看源和目标的对比结果，至此源分库分表中的数据已经按照目标的路由算法依次迁移到目标分库分表中，任务顺利完成。

最后

本文给的示例中，数据通过哈希分片策略路由算法，被精确分配到目标分片。原先 2x2 的分片系统迁移到 3x3 的过程中，系统通过目标分库分表的路由算法重新计算哈希值，确保每条数据进入对应的新分片，最终顺利完成了这项艰巨的任务。