MySQ分库分表与分区的区别和思考

一、数据库瓶颈的思考

不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。

1、IO瓶颈

第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 ->  分库和垂直分表。

第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 ->  分库。

2、CPU瓶颈

第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。

第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 ->  水平分表。

3、数据库拆分

数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。

数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。 举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。

综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率。

4、水平拆分

水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。

通常情况下，我们使用取模的方式来进行表的拆分;比如一张有400W的用户表users，为提高其查询效率我们把其分成4张表users1，users2，users3，users4
通过用ID取模的方法把数据分散到四张表内Id%4+1 = [1,2,3,4]
然后查询,更新,删除也是通过取模的方法来查询。

例：QQ的登录表。假设QQ的用户有100亿，如果只有一张表，每个用户登录的时候数据库都要从这100亿中查找，会很慢很慢。如果将这一张表分成100份，每张表有1亿条，就小了很多，比如qq0,qq1,qq1…qq99表。

用户登录的时候，可以将用户的id%100，那么会得到0-99的数，查询表的时候，将表名qq跟取模的数连接起来，就构建了表名。比如123456789用户，取模的89，那么就到qq89表查询，查询的时间将会大大缩短。

另外部分业务逻辑也可以通过地区，年份等字段来进行归档拆分;进行拆分后的表，只能满足部分查询的高效查询需求，这时我们就要在产品策划上，从界面上约束用户查询行为。比如我们是按年来进行归档拆分的,这个时候在页面设计上就约束用户必须要先选择年,然后才能进行查询;在做分析或者统计时，由于是自己人的需求,多点等待其实是没关系的,并且并发很低,这个时候可以用union把所有表都组合成一张视图来进行查询,然后再进行查询。

水平拆分的优点：

◆表关联基本能够在数据库端全部完成；

◆不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；

◆应用程序端整体架构改动相对较少；

◆事务处理相对简单；

◆只要切分规则能够定义好，基本上较难遇到扩展性限制；

水平切分的缺点：

◆切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则；

◆后期数据的维护难度有所增加，人为手工定位数据更困难；

◆应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。

5、垂直拆分

垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。表的记录并不多，但是字段却很长，表占用空间很大，检索表的时候需要执行大量的IO，严重降低了性能。这时需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。

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

1，把不常用的字段单独放在一张表；

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

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

例如学生答题表tt：有如下字段：

Id name 分数 题目 回答

其中题目和回答是比较大的字段，id name 分数比较小。

如果我们只想查询id为8的学生的分数：select 分数 from tt where id = 8;虽然知识查询分数，但是题目和回答这两个大字段也是要被扫描的，很消耗性能。但是我们只关心分数，并不想查询题目和回答。这就可以使用垂直分割。我们可以把题目单独放到一张表中，通过id与tt表建立一对一的关系，同样将回答单独放到一张表中。这样我们插叙tt中的分数的时候就不会扫描题目和回答了。

垂直切分的优点

◆ 数据库的拆分简单明了，拆分规则明确；

◆ 应用程序模块清晰明确，整合容易；

◆ 数据维护方便易行，容易定位；

垂直切分的缺点

◆ 部分表关联无法在数据库级别完成，需要在程序中完成；

◆ 对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求；

◆ 事务处理相对更为复杂；

◆ 切分达到一定程度之后，扩展性会遇到限制；

◆ 过读切分可能会带来系统过渡复杂而难以维护

二、分区表的实现原理

2.1 实现方式

具体如何实现上面链接里有写，这里只需记住如果表中存在主键或唯一索引时，分区列必须是唯一索引的一个组成部分。这个是数据库分的，应用透明，代码无需修改任何东西。

2.2 内部文件

先去data目录，如果不知道目录位置的可以执行：

接下来看下内部文件：

从上图我们可以看出，有2中类型的文件，.frm文件和.ibd文件

frm文件：表结构文件

ibd文件：InnoDB中，索引和数据都在同个文件.ibdata（你的执行结果可能是.MYD索引文件和.MYI数据文件，没关系，这是MyIsAm存储引擎，对应着InnoDB的.ibd文件）。因为Order这张表分为5个区，所以有5个这样的文件

par文件：你执行的结果可能有.par文件也可能没有。注意：从MySql 5.7.6开始，不再创建.par分区定义文件。分区定义存储在内部数据字典中。

2.3 数据处理

分区表后，提高了MySql性能。如果一张表的话，那就只有一个.ibd文件，一颗大的B+树。如果分表后，将按分区规则，分成不同的区，也就是一个大的B+树，分成多个小的树。

读的效率肯定提升了，如果走分区键索引的话，先走对应分区的辅助索引B+树，再走对应分区的聚集索引B+树。

如果没有走分区键，将会在所有分区都会执行一次。会造成多次逻辑IO！平时开发如果想查看sql语句的分区查询可以使用explain partitons select xxxxx语句。可以看到一句select语句走了几个分区。

mysql> explain partitions select * from TxnList where startTime>'2016-08-25 00:00:00' and startTime<'2016-08-25 23:59:00';+----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+| id | select_type | table             | partitions | type | possible_keys | key  | key_len | ref  | rows  | Extra       |+----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+|  1 | SIMPLE      | ClientActionTrack | p20160825  | ALL  | NULL          | NULL | NULL    | NULL | 33868 | Using where |+----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+

row in set (0.00 sec)

复制

三、分库分表的逻辑

当一张表随着时间和业务的发展，库里表的数据量会越来越大。数据操作也随之会越来越大。一台物理机的资源有限，最终能承载的数据量、数据的处理能力都会受到限制。这时候就会使用分库分表来承接超大规模的表，单机放不下的那种。

区别于分区的是，分区一般都是放在单机里的，用的比较多的是时间范围分区，方便归档。只不过分库分表需要代码实现，分区则是mysql内部实现。分库分表和分区并不冲突，可以结合使用。

3.1 实现

3.1.1 分库分表标准

存储占用100G+

数据增量每天200w+

单表条数1亿条+

3.1.2 分库分表字段

分库分表字段取值非常重要

1.在大多数场景该字段是查询字段

2.数值型

一般使用userId，可以满足上述条件

3.2 分布式数据库中间件

分布式数据库中间件分为两种，proxy和客户端式架构。proxy模式有、DBProxy等，客户端式架构有TDDL、等。那么proxy和客户端式架构有何区别呢？各自有什么优缺点呢？其实看一张图便可知晓。

proxy模式的话我们的select和update语句都是发送给代理，由这个代理来操作具体的底层数据库。所以必须要求代理本身需要保证高可用，否则数据库没有宕机，proxy挂了，那就走远了。

客户端模式通常在连接池上做了一层封装，内部与不同的库连接，sql交给smart-client进行处理。通常仅支持一种语言，如果其他语言要使用，需要开发多语言客户端。

各自的优缺点如下：

3.3 内部文件

找了一个分库分表+分区的例子，基本上和分区表的差不多，只是多了多了很多表的.ibd文件，上面有文件的解释：

[miaojiaxing@Grim testmydata]# ls | grep 'base_info'base_info_00.frmbase_info_00#P#p_2018.ibdbase_info_00#P#p_2019.ibdbase_info_00#P#p_2020.ibdbase_info_00#P#p_2021.ibdbase_info_00#P#p_init.ibdbase_info_00#P#p_max.ibdbase_info_01.frmbase_info_01#P#p_2018.ibdbase_info_01#P#p_2019.ibdbase_info_01#P#p_2020.ibdbase_info_01#P#p_2021.ibdbase_info_01#P#p_init.ibdbase_info_01#P#p_max.ibdbase_info.frmbase_info.ibd.4 问题

复制

3.4.1 事务问题

既然分库分表了，那么肯定涉及到分布式事务，如何保证插入到不同库的多条记录能够要么同时成功，要么同时失败。有些同学可能想到XA，XA性能差而且不需要使用5.7。柔性事务是目前主流的方案，TCC模式就属于柔性事务。

对于分布式事务问题每家公司有自己的实现，华为用saga，阿里用TXC，蚂蚁用DTX，支持FMT模式和TCC模式。

3.4.2 join问题

tddl、MyCAT等都支持跨分片join。但是尽力避免跨库join，比如通过字段冗余的方式等。

如果出现了这种情况且中间件支持分片join，那么可以这样使用。如果不支持可以手工查询。

四、分库分表策略

1、水平分库

1.概念：以 字段为依据 ，按照一定策略（hash、range等），将一个 库中的数据拆分到多个 库中。

2.结果：

每个 库的 结构都一样；

每个 库的 数据都不一样，没有交集；

所有 库的 并集是全量数据；

3.场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。

4.分析：库多了，io和cpu的压力自然可以成倍缓解。

2、水平分表

1.概念：以 字段为依据 ，按照一定策略（hash、range等），将一个 表中的数据拆分到多个 表中。

2.结果：

每个 表的 结构都一样；

每个 表的 数据都不一样，没有交集；

所有 表的 并集是全量数据；

3.场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。

4.分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。

3、垂直分库

1.概念：以 表为依据，按照业务归属不同，将不同的 表拆分到不同的 库中 。

2.结果：

每个 库的 结构都不一样；

每个 库的 数据也不一样，没有交集；

所有 库的 并集是全量数据；

3.场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。

4.分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

4、垂直分表

1.概念：以 字段为依据，按照字段的活跃性，将 表中字段拆到不同的 表（主表和扩展表）中。

2.结果：

每个 表的 结构都不一样；

每个 表的 数据也不一样，一般来说，每个表的 字段至少有一列交集，一般是主键，用于关联数据；

所有 表的 并集是全量数据；

3.场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。

4.分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

五、表分区的策略

目前在MySql中支持四种表分区的方式，分别为HASH、RANGE、LIST及KEY，当然在其它的类型数据库中，分区的实现方式略有不同，但是分区的思想原理是相同，具体如下：

 

1、HASH

HASH分区主要用来确保数据在预先确定数目的分区中平均分布，而在RANGE和LIST分区中，必须明确指定一个给定的列值或列值集合应该保存在哪个分区中，而在HASH分区中，MySQL自动完成这些工作，你所要做的只是基于将要被哈希的列值指定一个列值或表达式，以及指定被分区的表将要被分割成的分区数量。

 

比如：

CREATE TABLE t_product_item (

      id int(7) not null,

      title varchar(40) not null,

      subtitle varchar(60) null,

      price double not null,

      imgurl varchar(70) not null,

      producttype int(2) not null,

      createtime datetime not null

)

 ENGINE=InnoDB DEFAULT CHARSET=utf8

 PARTITION BY HASH(YEAR(createtime))

 PARTITIONS 10

;

上面的例子，使用HASH函数对createtime日期进行HASH运算，并根据这个日期来分区数据，这里共分为10个分区。

 

NOTE：

可以通过在CREATE TABLE 语句上添加一个“PARTITION BY HASH (expr)”子句，其中“expr”是一个返回整数的表达式。它可以是字段类型为MySQL 整型的一列的名字，也可以是返回非负数的表达式。另外，可能需要在后面再添加一个“PARTITIONSnum”子句，其中num 是一个非负的整数，它表示表将要被分割成分区的数量。

 

2、RANGE

基于属于一个给定连续区间的列值，把多行分配给同一个分区，这些区间要连续且不能相互重叠，使用VALUES LESS THAN操作符来进行定义。

 

比如：

CREATE TABLE t_product_item (

      id int(7) not null,

      title varchar(40) not null,

      subtitle varchar(60) null,

      price double not null,

      imgurl varchar(70) not null,

      producttype int(2) not null,

      createtime datetime not null

)

 ENGINE=InnoDB DEFAULT CHARSET=utf8

 PARTITION BY RANGE(producttype) (

      PARTITIONP0 VALUES LESS THAN(2),

      PARTITIONP1 VALUES LESS THAN(4),

      PARTITIONp2 VALUES LESS THAN(6),

      PARTITIONp3 VALUES LESS THAN MAXVALUE

);

 

上面的例子，使用了范围RANGE函数对产品类型进行分区，共分为4个分区，产品类别为0,1的对应在分区P0中，2,3类别在分区P1中，依次类推即可。那么类别编号大于6的怎么分区呢？我们可以使用MAXVALUE来将大于6的数据统一存放在分区P3中即可。

 

3、LIST

类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择分区的。LIST分区通过使用“PARTITION BY LIST(expr)”来实现，其中“expr” 是某列值或一个基于某个列值、并返回一个整数值的表达式，然后通过“VALUES IN (value_list)”的方式来定义每个分区，其中“value_list”是一个通过逗号分隔的整数列表。

 

比如：

DROP TABLE  IF EXISTS t_product_item;

CREATE TABLE t_product_item (

      id int(7) not null,

      title varchar(40) not null,

      subtitle varchar(60) null,

      price double not null,

      imgurl varchar(70) not null,

      producttype int(2) not null,

      createtime datetime not null

)

 ENGINE=InnoDB DEFAULT CHARSET=utf8

 PARTITION BY LIST(producttype) (

      PARTITIONP0 VALUES IN (0,1),

      PARTITIONP1 VALUES IN (2,3),

      PARTITIONP2 VALUES IN (4,5),

      PARTITIONP3 VALUES IN (6,7,8,9,10,11,12)

 )

 

上面的例子，使用了列表匹配LIST函数对产品类型进行分区，共分为4个分区，产品类别为0,1的对应在分区P0中，2,3类别在分区P1中，依次类推即可。那么类别编号大于12的怎么分区呢？这里不同于RANGE，LIST分区的数据必须匹配列表中的产品类别才能进行分区。

 

4、KEY

类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL 服务器提供其自身的哈希函数。必须有一列或多列包含整数值。

 

比如：

CREATE TABLE t_product_item (

      id int(7) not null,

      title varchar(40) not null,

      subtitle varchar(60) null,

      price double not null,

      imgurl varchar(70) not null,

      producttype int(2) not null,

      createtime datetime not null

)

 ENGINE=InnoDB DEFAULT CHARSET=utf8

 PARTITION BY KEY(producttype)

 PARTITIONS 10;

 

NOTE：

此种分区算法目前使用的比较少，大家知道其存在和怎么使用即可。

六、总结

分表和在用途上不一样，分表是为了承接超大规模的表，单机放不下那种。分区的话则一般都是放在单机里的，用的比较多的是时间范围分区，方便归档。性能稳定上的话都是一个个子表，差不多，区别应该是分区表是内部实现的，会比分表方案少一点数据交互只要你坚持，一步一步来，总归会成功的。切忌，学技术急不来，快就是稳，稳就是快。技术有限，接收指正。如果您觉得写的可以，请点个推荐。