关系型数据之分区分表分库

1.为什么需要分区分表分库

数据量达到一定规模，进行常规的sql语句优化已经效果不大的情况下，常见为mysql数据库，单表的记录达到1000W和空间占用至100G，可以扩充硬件，但是硬件收益已经不大的情况下，或者在预算有限的情况下，则需要进行优化数据库结构。这个时候就应该对数据进行拆分。

2.各种分区分表分库的情况

1.分区
分区是数据库本身的一个特性功能，将数据按照业务拆分成多个区，在业务上先判断属于哪个分区即可到指定分区查询，这样就可实现更快的查询速度了。
2.垂直分表
一个表的字段过多，根据实际业务访问获取数据的字段，将其拆分成两个表，就类似于副表，相当于单表转为一对一，如商品订单详情表，将订单的时间，商品各种基本信息作为主表，相对不重要的东西，或者需要点击多一步的东西作为副本表，通过增加访问接口的形式实现加速。
3.垂直分库
垂直分库，可根据业务，将有一定关系，但是耦合度不算高的表放到不同服务器的库中，变相增强硬件，各个库各司其职。比如商品库，店铺库等等
4.水平分库
一般优先垂直分库，之后再进行水平分库，常见商品库里，商品的记录很多，单表1500W+，可将原本的DB，变为DB1,DB2，结构一致，将数据根据id，进行%2+1然后分别插入（算法可以自定义），这样一个库就只有750W了，弊端数据库实例过多，导致运营维护不便。还有一种情况是做读写分离。
5.水平分表
同理水平分库，只是放在同一个实例，拆分维度由库变成表，可以对库里的数据一张表分为结构一致的多张表表，比如tb1,tb2,可以一样将数据根据id，进行%2+1进行保存（算法可以自定义），也可以将数据按照日期进行存储拜访，比如一个月，一年为维度等等。

3.弊端

3.1分区弊端

依赖于数据库特性，需要在sql明确知道属于哪个分区，相对来说基本属于硬编码，本质还是使用的一个数据库实例，吞吐量还是有限。且如果要分页展示难以实现跳页功能，需简化分页，比如使用流式或者只能上一页下一页这样的功能的分页效果。

3.2分表分库弊端

1.事务问题，由于实例分同一个，存在分布式事务问题
2.关联查询节点不同，如店铺和商品库，需要使用业务代码处理
3分页问题，升降序处理
4.实例或表不同，无法使用自增主键，会出现主键冲突，uuid不是趋势递增，难以使用id进行进行分库，需要一些分布式id的解决方案，比如雪花算法等等
5.公共表，一般数据量不是特别大，但是和各个业务联系相对紧密，如地区，常见做法，将地区表每个实例放一份，但是同步增删改是一个麻烦的事情