分表的目的
项目开发中,我们的数据库数据越来越大,随之而来的是单个表中数据太多。以至于查询数据变慢,而且由于表的锁机制导致应用操作也受到严重影响,出现了数据库性能瓶颈。
当出现这种情况时,我们可以考虑分表,即将单个数据库表进行拆分,拆分成多个数据表,然后用户访问的时候,根据一定的算法,让用户访问不同的表,这样数据分散到多个数据表中,减少了单个数据表的访问压力。提升了数据库访问性能。
举个栗子
比如咱们最常见的用户表(user表)
id | user_id | 其他字段 |
---|---|---|
主键id | 用户id | 其他字段 |
咱们一般都会用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表和各个分表之间的数据完全一致性,所以直接把查询的部分改掉是没有任何问题的
如果按照以上步骤执行,那么对线上的数据是没有任何影响的,而且我们线上就是这么操作了,经过了多次实践确保不会出问题,放心使用即可。如果这篇文章帮助到了你,记得点个赞哦。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。