mysql分表之后如何平滑上线详解

目录

• 分表的目的
• 举个栗子
• 分表策略
• 已经上线的运行中的表怎么办？
• 步骤1 上线双写
• 步骤2 全量同步
• 步骤3 查询新表数据
• 总结

分表的目的

项目开发中，我们的数据库数据越来越大，随之而来的是单个表中数据太多。以至于查询数据变慢，而且由于表的锁机制导致应用操作也受到严重影响，出现了数据库性能瓶颈。

当出现这种情况时，我们可以考虑分表，即将单个数据库表进行拆分，拆分成多个数据表，然后用户访问的时候，根据一定的算法，让用户访问不同的表，这样数据分散到多个数据表中，减少了单个数据表的访问压力。提升了数据库访问性能。

举个栗子

比如咱们最常见的用户表（user表）

咱们一般都会用user_id去查询对应的用户信息，但是随着业务的增长，这张表会越来越大，甚至上亿，严重影响了查询性能。 所以咱们就会对这张表进行分表处理，分到多张表减小查询压力

分表策略

以分10张表为例(具体分多少张表 根据实际情况来估算) 首先咱们建10张表 user1、user2、user3。。。。。user10

一般情况下，我们都会用作为索引的字段(user_id)进行取模处理。想分多少张表，就按照多少取模，比如这个case就是10

$table_name = $user_id % 10;

按照上面的取模公式

• user_id为1295的会落在user5里面
• user_id为8634的会落在user4里面
• 。。。。。。。

「每次CURD根据上面查找表的策略进行就行了」，这个问题不大，我们暂且先不多说。

已经上线的运行中的表怎么办？

其实上面的方法大家应该都知道怎么用，但是有个问题，已经上线了的表怎么办？那张表的数据在线上是一直被查找或者改变的。如何能够进行平滑的分表，并且让用户无感知呢？

方法1

直接上线，提前写个脚本，脚本内容是把旧表(user)的数据同步到user1表到user10表，一上线了赶紧执行

这种方法明显是行不通的，主要是存在以下问题

• 如果执行过程中脚本有问题怎么办？代码全部回滚？
• 脚本把把旧表(user)的数据同步到user1表到user10表，这个脚本得执行多久？ 如果是1个小时，那么这段时间线上和这张表相关的业务都是不正常的

这显然是行不通的，对线上影响很大。

方法2

先写个同步数据的脚本，脚本内容是把旧表(user)的数据同步到user1表到user10表，脚本同步完了再上线。

这个方法看起来友好了一些，不过也存在一些问题。

• 脚本同步完，立即上线，这两件事之间是有一些时间差的，这个时间差中线上表可能有一些改动，这些改动怎么办？

「以上两种方法看起来貌似都行不通，所以看来得来点不一样的了。咱们直接看结论。」

步骤1 上线双写

首先咱们把双写上线了，什么意思呢？比如user_id=123，对于增加，删除，修改操作来说，咱们既操作user表，也操作user_id=123对应的user3表。

function modify($user_id){  //包含增加，删除，修改操作
  modify_user();  //modify user表
  $table_name = $user_id % 10;
  modify_user($table_name) //modify对应的分表
}

因为查询的部分还是在user表中查询的，所以上面的操作对线上用户是无任何影响的。

步骤2 全量同步

写一个全量同步user表到user1-user10的表，最好找个低峰期执行脚本，以防万一影响user表的查询

这一步执行之后，因为咱们之前上线了双写(见步骤1)，所以user表和user1-user10表之间的数据已经是完全一致的了。

步骤3 查询新表数据

将查询的部分改到user1-user10

因为前面两个步骤咱们已经保证了user表和各个分表之间的数据完全一致性，所以直接把查询的部分改掉是没有任何问题的

如果按照以上步骤执行，那么对线上的数据是没有任何影响的，而且我们线上就是这么操作了，经过了多次实践确保不会出问题，放心使用即可。

总结

到此这篇关于mysql分表之后如何平滑上线的文章就介绍到这了,更多相关mysql分表平滑上线内容请搜索NICE源码以前的文章或继续浏览下面的相关文章希望大家以后多多支持NICE源码！