一分库分表_基本概念

Posted 2022-01-07 上善若水

一、为什么要分库分表？

谈及到分库分表，肯定要扯到高并发了。因为分库分表一定是为了支撑高并发、数据量大两个问题。说白了，分库分表是两回事，可千万别搞混了。可能是光分库不分表，也可能是光分表不分库，都有可能。

1.1、分表：

比如你单表都几千万数据了，你确定你能抗住么？绝对不行，单表数据量太大，会极大影响你的SQL执行的性能，到了后面你的SQL可能就跑的很慢了。一般来说，就以我的经验来看，单表到几百万的时候，性能就会相对差一些了，你就得分表了。
分表是啥意思？就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户id来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在200万以内。

1.2、分库：

分库是啥意思？就是你一个库，一般我们经验而言，最多支撑到并发2000，一定要扩容了，而且一个健康的单表并发值你最好保持在每秒1000左右，不要太大。那么你就可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。

1.3、分库分表前后对比

#	分库分表前	分库分表后
并发支撑情况	mysql单机部署，扛不住高并发	MYSQL从单机到多级，能承受的并发增加了多倍
磁盘使用情况	MYSQL单机磁盘容器几乎撑满	拆分为多个库，数据库服务器磁盘使用了大大降低
SQL执行性	单表数据量太大，SQL越跑越慢	单表数据量减少，SQL执行效率明显提升

二、数据切分

数据切分可以分为：垂直切分和水平切分。

2.1、垂直切分

垂直切分又可分为：垂直分库和垂直分表。

2.1.1、垂直分库

概念：就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似。

每隔微服务使用单独的一个数据库。

如图：

结果：

• 每个库的结构都不一样；
• 每个库的数据也不一样，没有交集；
• 所有库的并集是全量数据；

说明
一开始我们是单体服务，所以只有一个数据库，所有的表都在这个库里。

后来因为业务需求，单体服务变成微服务治理。所以将之前的一个商品库，拆分成多个数据库。每个微服务对于一个数据库。

2.1.2、垂直分表

概念：把一个表的多个字段分别拆成多个表，一般按字段的冷热拆分，热字段一个表，冷字段一个表。从而提升了数据库性能。

如图：

结果：

• 每个表的结构都不一样；
• 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
• 所有表的并集是全量数据；

说明：

一开始商品表中包含商品的所有字段，但是我们发现：

1. 商品详情和商品属性字段较长。
2. 商品列表的时候，我们是不需要显示商品详情和商品属性信息，只有在点击进去商品的时候才会展示商品详情信息。

所以可以考虑把商品详情和商品属性单独切分一张表，提高查询效率。

2.1.3、垂直切分优缺点

优点：

• 解决业务系统层面的耦合，业务清晰
• 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
• 高并发场景下，垂直切分一定程度上提升IO、数据库连接数、单机硬件资源的瓶颈

缺点：

• 分库后无法join，只能通过接口聚合方式解决，提升了开发的复杂度
• 分库后分布式事务处理复杂
• 依然存在单表数据量过大的问题（需要水平切分）

2.2、水平切分

当一个应用难以再细粒度的垂直切分或切分后，数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。

水平切分也可以分为：水平分库和水平分表。

2.2.1、水平分库

水平分库的原因：

上面虽然已经把商品库分成3个库，但是随着业务的增加一个订单库也出现QPS(每秒查询率(Query Per Second) )过高，数据库响应速度来不及，一般MySQL单机也就1000左右的QPS，如果超过1000就要考虑分库。

如图：

结果：

• 每个库的结构都一样；
• 每个库的数据都不一样，没有交集；
• 所有库的并集是全量数据；

2.2.2、水平分表

概念：一般我们一张表的数据不要超过1千万，如果表数据超过1千万，并且还在不断增加数据，那就可以考虑分表。

如图：

结果：

• 每个表的结构都一样；
• 每个表的数据都不一样，没有交集；
• 所有表的并集是全量数据；

2.2.3、水平切分优缺点

优点：

• 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
• 应用端改造较小，不需要拆分业务模块

缺点：

• 跨分片的事务一致性难以保证
• 跨库的join关联查询性能较差
• 数据多次扩展难度和维护量极大