实战中，数据库应如何分库分表

数据库如何分库分表

首先说数据库的分库和分表是两个完全不同的概念。不能混为一谈。但是他们的作用基本上都是为了抗住更大的并发量。

因为在实际生产中，数据库的访问瓶颈是最大概率限制服务器并发性能的。

随着业务的开展，数据库中的数据会大量产生，当表中的数据量达到千万级别的时候，就需要进行分表了，否则一条sql语句查询可能就会耗时很久。

而如果部分库的话，数据库的访问数量就是一个限制最大的点，大量请求过来访问数据库，结果数据库连接达到瓶颈了，那么就会产生大量的阻塞。

切分策略：

1.垂直拆分

2.水平拆分

垂直拆分：

1.垂直分表

​ 基于数据库中表的列进行，可以将不同的字段进行拆分，从而减小每一个表中的列的个数，将大表拆成了小表。这两个表的结构是不同的，只不过可以通过冗余字段来进行关联查询。最常见的方式就是 热点、冷点数据的拆分。

​ 可以防止在进行sql查询的时候，一列查询的数据太多，导致跨页，造成不必要的开销。而且每一行的数据越少，加载到内存的数据就越多，就能更好的减少磁盘IO的次数。

2.垂直分库

​ 根据业务的耦合性，将关联不大的表存储在不同的数据库里面，与微服务架构类似，按照业务逻辑分类来进行独立的划分。

​ 这样可以使业务系统更加清晰，耦合度降低，可以针对不同的业务的数据进行分级管理。在高并发的情况下，在一定程度上能投提高数据库的连接数还有IO瓶颈。

​ 缺点 的话就是会导致部分表无法关联查询，只能通过微服务的远程调用 也就是 接口聚合的方式来实现，提高了复杂度。还有就是分布式事务处理起来比较复杂。仍然存在单表数据量大的问题。

水平拆分

​ 将一个数据量大的表进行水平拆分成多张表，每个表的格式相同，只是数据不同。根据需求选择不同的逐渐策略。我一般采用主键自增，也就是 每张表设置不同的起始数字，然后设置步长，使得每个表逻辑合在一起的时候，仍然是一个自增的顺序。

​ 可以实现因为某一个不能再细粒度的垂直分表的情况下，减少每张表的数据量。能够用更多的库来承担更大的并发量。

路由规则

水平拆分之后，数据都是分在不同的库或者表里面，如何知道哪条数据在那个库或者表里，需要路由算法来进行计算。这个算法会引入一定的复杂性。

范围路由：

选择有序的数据列，作为路由的条件，根据不同分段分散到不同的数据库表中，举个例子拿用户id 来说，可以将前0-500W放在一个数据库的表里面， 500W+1 - 1000W放到另外一个数据库的表里面，一次类推。

这样就可以根据范围进行路由了。但是这种方法复杂的地方就在于这个范围的选择。

但是他的好处也就是你后续扩充的话 ，简单方便，原来的数据不用进行改动。

缺点就是 容易造成热点数据的访问倾斜，热点数据集中在一个表里面。

Hash算法：

选取一个列或者多个列进行hash运算，然后根据hash 的结果将不同的数据分散到不同的数据库中，有点那种散列表的意思，然后后续访问的时候使用同样的hash运算，就可以找到在哪个表里面了。

hash算法的复杂点就在于 在出师表的数量的选取上，也就是hash算法的 基数的选择。

hash算法的优缺点和范围路由的优缺点正好相反。。

路由配置

路由配置就是设置一个路由表，用一张独立的表来记录陆游信息。我们将数据存放的位置存放到这个表里面。

优点是：后续改动方便，只需要改动路由表 。

缺点就是 每次必须多查询一次路由表，而且随着数据量的增大，路由表也会成为瓶颈点。

基于以上问题，我们就使用到了分库分表的中间件！

分库分表的中间件：

sharding-jdbc

当当开源的，属于client层。 支持的sql语法比较多，没有太多限制。支持分库分表，读写分离，分布式id生成，柔性事务。

mycat

阿里开源的，基于cobar改造的，属于proxy层，支持的功能非常完善。

支持分布式事务，支持通过全局表，ER关系的分片策略，支持多表关联查询，支持分布式下的主键生成问题等。

需要部署，运维成本高，好处在于对于各个项目是透明的，更改配置或者升级的话只要在中间件里面进行就可以

如何在设计表初期就尽量减少后续可能存在的分表操作呢？

1.在开发设计表的时候，就要根据经验考虑一下冷热点数据的拆分，要将冷点和热点数据分到两个表里面，通过冗余字段来进行关联。

2.每个表的列不要太多，如果有业务逻辑的话，就使用冗余字段来进行关联。

3.在设计的时候，能够使用int就不要使用char，类似标识位，可以用0,1 来替代 是否。类似这样的思想。

4.根据不同的业务逻辑需求，将不同的表都放入到不同的库中。

5.有业务逻辑关联的表，可以使用公共字典表来进行关联，字典表里面的数据量不会特别大，但是会帮助查询表省用大量的空间。