前文我们讲了如何分库分表，现在假设我们已经做好了分库分表，把原来的单库单表的设计改造成了多库多表结构，那么如何进行数据迁移呢？
一般会有这几种方案：
停机迁移方案
双写迁移方案
停机迁移方案
这种方案最简单也是最low的。
数据迁移前，在网站或者app挂个公告，说0点到早上6点系统进行维护，无法访问。
接着到0点停机，系统停掉，就没有流量写入了，此时老的单库单表就不会有新数据写入了。然后你用提前写好迁移数据的工具，将单库单表的数据哗哗哗读出来，写到分库分表里面去。
迁移完了之后，修改系统的数据库连接配置啥的，包括可能代码和SQL也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。
这些工作做完之后，验证一下系统，如果没什么问题， 整个迁移工作就结束了，还是画个示意图让大家更有感觉写。
图1 基于sharding-shpere迁移数据
图2 基于mycat迁移数据
停机迁移数据，其主要缺点是必须停机几个小时，而且如果一旦迁移没成功，必须切回原来的单库单表方案，下次还得发公告再次停机迁移数据。
有的项目一旦上线就不能停止运行，那么上面的方案就无法实行了。而且现在比较主流的迁移方案是不停机双写迁移方案。所以下面我们介绍下双写迁移方案，在不停机的情况完成系统的无缝切换。
双写迁移方案
简单来说，就是在线上系统里面，之前所有对数据库增删改的操作，除了对老库增删改，都加上对新库的增删改，这就是所谓的双写。
然后新系统部署上线后，用数据迁移工具，读老库数据写到新库。如果读出来的数据在新库里没有，或者这条数据的update_time最后修改的时间，比新库的数据新才会写。简单来说，就是不允许用老数据覆盖新数据。
导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，对比新老库每个表的每条数据，如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。
接着当数据完全一致了，就 ok 了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么。所以现在基本玩儿数据迁移之类的，都是这么干的。
图3 双写不停机迁移数据方案
双写不停机迁移数据方案，能无缝的升级系统，但要注意数据的准确性，必须做好数据的验证，不能用旧数据覆盖新数据。
END
