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分表平滑上线内容请搜索潘少俊衡以前的文章或继续浏览下面的相关文章希望大家以后多多支持潘少俊衡！