分库分表技术

---

1 什么是分库分表

单库数据量的巨大，以及业务复杂性导致单表的数据量过大后，会导致数据的查询效率变慢，以及数据插入变慢，（表需要维护巨大的索引树等），这个时候，我们就需要对于数据库进行分库分表操作。
（这里的分库分表并不是解决这个问题的唯一方式，它只是其中的一个解决策略，实际上，在引入分库分表之后，会给系统带来额外的复杂性）

对于分库分表的策略（或者说是实现方式），主要分为垂直切分和水平切分：

垂直切分：

对于分库而言，垂直切分是对于业务层面的切分，比如我们可以对用户，日志，订单等进行分库设计，让每一个独立的模块都具有一个库，这也是目前微服务架构下的基本设计方式

对于分表而言，垂直切分是针对于其表字段的切分，比如我们的一个订单表，其含有的字段为，订单id，订单详情，订单数量，订单号，订单人员，订单人员信息，订单发起时间，。。。，对于一个单体表结构而言，其内部含有的字段不宜过多，因此我们可以使用大表拆小表的方式进行垂直分表，

对于垂直切分表而言，他的优点是能够进行业务解耦，并且单表的压力减轻，便于业务数据的存储和查询，但是，过多的进行垂直切分表，会造成多表join，从而影响业务数据的查询，以及分布式事务的处理。

水平切分：

水平切分是针对于表数据的处理，在大型分布式环境下，我们可以通过将一个表中的数据以某一个字段（取模），拆分到多个表中，

对于分表而言，业务的数据会通过分表策略分散到不同的表中（每一个表的数据设计结构都是相同），同时不同的表也会分散到不同的数据服务器中，通过水平拆分表的方式，使单表的数据保持在一定的数目，提高单表的查询效率（对应查询，我们要有相应的机制，因为单表的数据最终分散到了每一个分表中），但是对于分表而言，分表扩容问题，以及分表的分片规则难以统一，例如对应A表我们需要通过用户id进行取模，但是对应B表我们就需要对订单id进行取模，以及分布式事务问题都是分表相对于单体表接口而言难以解决的问题。

2 分库分表解决了什么问题

对于大型分布式服务而言 ，分库分表解决了单库模式下，数据量巨大，查询效率降低，数据库服务负载压力大。

3 分库分表处理数据库自增id问题

• 1，设置数据库 sequence 或者表自增字段步长
• 2，分布式服务唯一id
• 3，UUID（不考虑）
• 4，id追加系统时间

4 mycat和sharding-jdbc的区别

针对于mycat和sharding-jdbc的区别，建议大家可以看一下官方文档，并且跟着官方文档做一下，理解原理，才能进行比较。

对于这两个区别，知乎是开了一个话题：mycat和sharding-jdbc哪个比较好？各有什么优缺点？ ，个人还是比较赞同第一个人的评论，使用过后，会发现mycat确实配置过于复杂

4.1 mycat原理

Mycat是一个开源的分布式数据库系统，是一个实现了MYSQL协议的服务器，前端用户可以把它看作是一个数据库代理，MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。

官方文档：http://www.mycat.org.cn/about.html

4.2 sharding-jdbc原理

Sharding-jdbc定位wei轻量级的Java框架，在JAVA的JDBC层提供额外的服务，它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

官方文档:
https://shardingsphere.apache.org/document/legacy/4.x/document/cn/overview/#sharding-jdbc
社区讲解：
https://www.bilibili.com/video/BV1Sb411H7E7