浅谈系统数据库迁移到分库分表中

系统数据库迁移到分库分表中

当我们系统被大量请求访问之后，数据库可能就扛不住了，在这种时候我们就可以考虑数据库分库分表了，但是分库分表的过程时，怎么在不影响客户使用系统的情况下进行系统数据迁移呢？接下来我给大家两个方案进行参考。

（1）停机迁移方案

我们先说一个最简单的方案，很简单，大家伙儿凌晨12点开始运维，网站或者app挂个公告，说0点到早上6点进行运维，无法访问。

接着到0点，停机，系统停掉，没有流量写入了，此时老的单库单表数据库静止了。然后你之前得写好一个导数据的一次性工具，此时直接跑起来，然后将单库单表的数据哗哗哗读出来，写到分库分表里面去。

导数完了之后，就ok了，修改系统的数据库连接配置啥的，同时代码和SQL也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。

验证一下，ok了，完美，大家伸个懒腰，看看成都凌晨4点钟的夜景，打个滴滴回家吧

但是这个方案过于简单，谁都能干，我们来看看高大上一点的方案

（2）双写迁移方案

这个是我们常用的一种迁移方案，比较靠谱一些，不用停机，不用看成都凌晨4点的风景。

简单来说，就是在线上系统里面，之前所有写库的地方，比如增删改操作，除了对老库进行增删改操作外，还要加上对新库的增删改操作，这就是所谓双写，同时写俩库：老库和新库。

然后系统部署之后，新库数据差太远，用之前写好的导数据的工具跑起来，读老库的数据，然后写进新库中，写的时候要根据修改时间这类字段，判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。

接着导数据，如果一轮之后，数据还是存在不一致的地方，那么做一个自检程序，程序自动将新库与老库的数据做一轮校验，比对新老库每个表的每条数据，如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。

最后当数据完全一致了，就ok了，基于仅仅使用分库分表的最新代码，重新部署一次，那么之后就将仅仅基于分库分表在操作了，还没有几个小时的停机时间，很稳。