当出现这种情况时，我们可以考虑分表，即将单个数据库表进行拆分，拆分成多个数据表，然后用户访问的时候，根据一定的算法，让用户访问不同的表，这样数据分散到多个数据表中，减少了单个数据表的访问压力。提升了数据库访问性能。
举个栗子
比如咱们最常见的用户表(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表和各个分表之间的数据完全一致性，所以直接把查询的部分改掉是没有任何问题的。
如果按照以上步骤执行，那么对线上的数据是没有任何影响的，而且我们线上就是这么操作了，经过了多次实践确保不会出问题，放心使用即可。
