MySQL(十二)-分库分表

参考文献

MySQL:互联网公司常用分库分表方案汇总！

为什么要分表

不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值.在业务Service来看就是,可用数据库连接少甚至无连接可用.接下来就可以想象了吧(并发量、吞吐量、崩溃).

IO瓶颈

磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表.
网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库.

CPU瓶颈

SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算.
单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水平分表.

分库分表

水平分库

概念:
- 以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中
- 将单张表的数据切分到多个服务器上去,每个服务器具有相应的库与表,只是表中数据集合不同. 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力,突破IO、连接数、硬件资源等的瓶颈.
结果:
- 每个库的结构都一样;
- 每个库的数据都不一样,没有交集;
- 所有库的并集是全量数据;
场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库
分析:库多了,IO和CPU的压力自然可以成倍缓解.

水平分表

概念:
- 以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中.
- 针对数据量巨大的单张表(比如订单表),按照某种规则(RANGE,HASH取模等),切分到多张表里面去. 但是这些表还是在同一个库中,所以库级别的数据库操作还是有IO瓶颈.不建议采用.
结果:
- 每个表的结构都一样;
- 每个表的数据都不一样,没有交集;
- 所有表的并集是全量数据;
场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈.
分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担.

水平分库分表切分规则

RANGE

从0到10000一个表,10001到20000一个表;
HASH取模

一个商场系统,一般都是将用户,订单作为主表,然后将和它们相关的作为附表,这样不会造成跨库事务之类的问题. 取用户id,然后hash取模,分配到不同的数据库上.
地理区域

比如按照华东,华南,华北这样来区分业务,七牛云应该就是如此.
时间

按照时间切分,就是将6个月前,甚至一年前的数据切出去放到另外的一张表,因为随着时间流逝,这些表的数据被查询的概率变小,所以没必要和“热数据”放在一起,这个也是“冷热数据分离”.

垂直分库

概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中.
结果:
- 每个库的结构都不一样;
- 每个库的数据也不一样,没有交集;
- 所有库的并集是全量数据;
场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块.
分析:到这一步,基本上就可以服务化了.例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化.再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化.

垂直分表

概念:
- 以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中.
- 也就是“大表拆小表”,基于列字段进行的.一般是表中的字段较多,将不常用的, 数据较大,长度较长(比如text类型字段)的拆分到“扩展表“.一般是针对那种几百列的大表,也避免查询时,数据量太大造成的“跨页”问题.
结果:
- 每个表的结构都不一样;
- 每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据;
- 所有表的并集是全量数据;
场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大.以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈.
分析:可以用列表页和详情页来帮助理解.垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表.这样更多的热点数据就能被缓存下来,进而减少了随机读IO.拆了之后,要想获得全部数据就需要关联两个表来取数据.但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上).关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据.