数据库分库分表

此文章，是我针对分库分表的概念的理解，为什么要分库分表，分完之后有什么效果。分库分表会有什么问题。做出了一些解释和说明。所以，市面上会有各种 分库分表中间件 的产出。（参考了视频的教程）

 

解决痛点：数据量过大。对关系型数据库性能，造成影响。访问性能变慢。

例子：例如一个数据库有3张表，一个是商品信息表，一个是店铺表，一个是区域表。

问题：目前要根据商品ID 展示出 商品的描述，店铺的名称，和店铺所在的城市名字。那么就是3张表关联查询。如果3张表数据量越来越大，单表数据量超过1000W。再像之前这么查，是不可能了。增加索引也是一样的。还是慢。

想到的解决方案：

• 方案一：增加单机的硬件性能，但是mysql数据库对硬件的支持是有上限的。还是解决不了根本问题。

• 方案二：将原有数据库，根据业务拆分成多个数据库；大表拆分成多个小表。使得将大数据量，平摊到各个单一的数据库，减少了数据量。通过这种方式，来解决数据库性能问题。

   

分库分表包括分库和分表两个部分，在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表四种方式。

 

• 垂直分表：根据业务，将一个表的字段，分成多个表，每个表存储一部分字段。

那么就是将商品信息表，分成一个商品基本信息表，一个商品详情信息表。

它带来的提升是：

1.为了避免IO争抢并减少锁表的几率。

2.充分发挥热门数据的操作效率。

通常我们按以下原则进行垂直拆分:

1. 把不常用的字段单独放在一张表;

2. 把text，blob等大字段拆分出来放在附表中;

3. 经常组合查询的列放在一张表中;

 

• 垂直分库：垂直分表性能有一定的上限，毕竟还是在同一个数据库中，同一台服务器。每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。所以，按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。

那么就是将商品的表，放一个数据库；店铺表放一个数据库；区域表放一个数据库。

它带来的提升是：

1. 解决业务层面的耦合，业务清晰

2. 能对不同业务的数据进行分级管理、维护、监控、扩展等

3. 高并发场景下，垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈

 

• 水平分库：针对商品信息表所在的数据库，2张表的数据量还在增加。单表的数据量也超过了千万。单台也无法支持了。所以，

把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。

垂直分库是把不同表拆到不同数据库中，水平分库是对数据行的拆分，不影响表结构

那么就是将商品信息数据库，将数据划分为2个数据库，2个数据库表结构还是一样的。每个数据库还是2张表。根据商品的ID的单数，双数，将商品信息的数据分为了2部分。

它带来的提升是：

1. 解决了单库大数据的压力，性能瓶颈。

2. 提高了系统的稳定性及可用性。（稳定性体现在IO冲突减少，锁定减少，可用性指某个库出问题，部分可用）

 

• 水平分表：如果表的数据量继续增加，继续采用那种水平分库的方式，那么数据库实例会越来越多。难以去维护。所以，

还是针对表，不是针对字段了。还是针对数据，在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。

那么我再将上诉的商品信息2个数据库中，每个数据库的那俩张表的数据，再进行一个拆分。按照店铺的ID的单数，双数，再进行一个划分。也就是，这个商品信息，2个库，每个库2套表（商品基本信息+商品详细信息），表结构一样，数据不一样。

 

它带来的提升是：

1. 优化单一表数据量过大而产生的性能问题

2. 避免IO争抢并减少锁表的几率

 

总结：垂直分表和垂直分库，是从数据库的结构来划分，垂直分表是按照表的字段，垂直分库是按照表的分类。一般是数据库设计的时候考虑这俩种方式。

水平分库和水平分表，是按照数据行的方式去划分，水平分库，将一个表的数据按照规则划分为多个库。水平分表，将一个表的数据按照规则拆分多个表。一般是后期单表数据量大了，采用这俩种方式。不过，单表数据量不是特别大。首先考虑，缓存，读写分离，索引等方案。

 

这4种方式所带来的问题：

1. 事务一致性问题，带来分布式事务的问题。

2. 跨数据库实例关联查询。

3. 分页，排序也复杂了。

4. 主键可能会重复。

5. 公共表，比如参数表，联合查询频率较高。