【分库分表】理论基础
目录
为什么要分库分表
垂直分
垂直分库
垂直分表
垂直切分优缺点
优点
缺点
水平分
水平分库
水平分表
水平切分优缺点
优点
缺点
为什么要分库分表
分库分表是一种场景解决方案，它的出现是为了解决一些场景问题的
-
单表过大的话，读请求进来，查数据需要的时间会过长，当一张表的数据达到几千万时，查询一次所花的时间会变长。业界公认MySQL单表容量在 1千万 以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。
-
读请求过多，单节点IO压力太大，IO压力太大会造成什么？可能会造成IO阻塞，造成响应速度变慢。
分库分表有两种维度，一种维度是分库，另一种维度是分表。分的话有两种分法，一种是水平分，另一种是垂直分。
垂直分
垂直切分又可以分为: 垂直分库和垂直分表。
垂直分库
就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，
每个微服务使用单独的一个数据库。
一开始我们是单体服务，所以只有一个数据库，所有的表都在这个库里。
后来因为业务需求,单体服务变成微服务治理。所以将之前的一个商品库，拆分成多个数据库。每个微服务对于一个数据库。
垂直分表
把一个表的多个字段分别拆成多个表，一般按字段的冷热拆分，热字段一个表，冷字段一个表。从而提升了数据库性能。
一开始商品表中包含商品的所有字段，但是我们发现:
商品详情和商品属性字段较长。商品列表的时候我们是不需要显示商品详情和商品属性信息，只有在点进商品商品的时候才会展示商品详情信息。
所以可以考虑把商品详情和商品属性单独切分一张表，提高查询效率。
垂直切分优缺点
优点
- 解决业务系统层面的耦合，业务清晰
- 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
- 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点
- 分库后无法Join，只能通过接口聚合方式解决，提升了开发的复杂度
- 分库后分布式事务处理复杂
- 依然存在单表数据量过大的问题（需要水平切分）
水平分
当一个应用难以再细粒度的垂直切分或切分后数据量行数巨大,存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分也可以分为：水平分库和水平分表。
水平分库
上面虽然已经把商品库分成3个库，但是随着业务的增加一个订单库也出现QPS过高，数据库响应速度来不及,一般mysql单机也就1000左右的QPS，如果超过1000就要考虑分库。
水平分表
一般我们一张表的数据不要超过1千万,如果表数据超过1千万，并且还在不断增加数据，那就可以考虑分表。
水平切分优缺点
优点
- 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
- 应用端改造较小，不需要拆分业务模块
缺点
- 跨分片的事务一致性难以保证
- 跨库的Join关联查询性能较差
- 数据多次扩展难度和维护量极大