分库分表概念、使用场景、带来的问题

 参考文章：分库分表的概念及应用场景详解_star++的博客-CSDN博客 

         随着互联网的发展,线上业务越来越普及,用户量也是越来越大,那么必定导致用户量的增加,业务压力增大. 服务器的处理请求压力已经通过分布式微服务解决, 那么存储层的压力也需要有解决方案：分库分表。

下面举例说明数据库表的几种拆分方式：

如：user表。

1、水平分表

        user表 水平拆分后，分为：user1、user2 两张表，拆分后的两张表结构相同。

        水平分表可以很好缓解数据存储大,导致即使使用了索引,那检索很慢的问题。比如mysql上千万条数据时,使用索引性能也开始下降了,这时候分表,那么每张表只有500万数据,可以很好解决索引瓶颈问题。

 2、垂直分表

        user表 垂直拆分后，分为：user1、user2 两张表，拆分后的两张表结构不同。即：将user表进行细化拆分, user1 ：年龄信息，user2：img信息。

垂直分表有两个好处：

        1、可以一定程度上解决索引的瓶颈,因为可以让一颗b+树存储更多的数据,比如有图片大文本数据,垂直分表,就有主从表的概念,这样大大提高检索效率;

        2、可以提高并发操作,可以达到同时修改两张表的数据,不会局限于行锁。

 3、水平分库

         user表 水平分库后，分为：DB1库的user表、DB2库的user 表，拆分后的两张表结构相同。

        水平分库一般不是因为索引瓶颈导致的, 而是因为业务并发量太大造成的, 一个数据库已经不能够及时处理所有的业务请求了,必须将数据库请求进行分摊处理.如果不是因为数据库处理不过来,一般水平分表就够用了,水平分表只是解决存储量大的索引瓶颈问题

4、垂直分库

        垂直分库：将用户模块、订单模块 放在不同的库里。

        垂直分库一般也不是因为索引瓶颈导致的,也是因为业务量大造成的,一般是指单块业务就很大,必须独立使用一台数据库服务才能及时处理. 否则业务量不大情况,所有模块业务表分不同schema即可。

5、使用场景

水平分表：业务并发量不大, 单表数据大,检索数据慢；
垂直分表：业务并发量不大, 大表,存大文本；
水平分库：业务并发量大,单表数据大；
垂直分库：业务并发量大, 业务模块分库,单模块业务量大。

6、总结

        1、如果只是数据量大,达到了索引瓶颈,那么只需要分表即可；

        2、如果是数据量和并发量都大, 那么达到了io和cpu瓶颈,那么需要分库。

7、分库分表带来的问题

7.1、分布式事务问题

        数据库的事务只是在本地是有效的,能保证结点本身的的操作是一个事务.当多个数据库时,数据库之间是不可见的,所以存在分库时数据不一致性问题。

7.2、跨结点关联查询问题

        当垂直分库的时候,比如订单和支付是不同模块,那么这个时候想查看订单详情,那么需要关联查询,那么再也不能像单库那样,直接使用join就能达到预期效果了。

7.3、跨结点排序,分页,max,min,count等问题

        当水平分库的时候,每个数据库结点都是保存一部分数据,那么排序,分页,max,min,count是对整体数据的操作,也不能像单库那样,直接使用order by, limit, max,min,count(*)就能解决了

7.4、主键重复问题

        当水平分表分库的时候,主键的生成策略就没用了,水平分库分表就不能依赖表本身主键生成策略了,否则很可能发生重复。

7.5、公共表问题

        一些共用表,比如一些常量表,是多个数据库结点都要使用到的,但是不需要分库分表的。

7.6、总结

        虽然分库分表可以给我们解决数据库性能问题，但是也会给我们带来上面的五个问题，可能在开发当中需要解决，这些解决方案在一些中间件已经帮我们解决了,我们只需要使用这些中间件的方案即可。