MySQL之分库分表

MySQL之分库分表

1.问题分析

随着互联网及移动互联网的发展，应用系统的数据量也是成指数式增长，若采用单数据库进行数据存储，存在以下性能瓶颈：
1.IO瓶颈：热点数据太多，数据库缓存不足，产生大量磁盘IO，效率较低。 请求数据太多，带宽不够，网络IO瓶颈。
2.CPU瓶颈：排序、分组、连接查询、聚合统计等SQL会耗费大量的CPU资源，请求数太多，CPU出现瓶颈。

2.分库分表介绍

为了解决上述问题，我们需要对数据库进行分库分表处理。
分库分表的中心思想都是将数据分散存储，使得单一数据库/表的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的

3.分库分表拆分策略

分库分表的形式，主要是两种：垂直拆分和水平拆分。而拆分的粒度，一般又分为分库和分表，所以组成的拆分策略最终如下:

在业务系统中，为了缓解磁盘IO及CPU的性能瓶颈，到底是垂直拆分，还是水平拆分；具体是分
库，还是分表，都需要根据具体的业务需求具体分析。

4.垂直分库

4.1介绍

垂直分库：以表为依据，根据业务将不同表拆分到不同库中

4.2特点

特点：
1.每个库的表结构都不一样。
2.每个库的数据也不一样。
3.所有库的并集是全量数据

5.垂直分表

5.1介绍

垂直分表：以字段为依据，根据字段属性将不同字段拆分到不同表中

5.2特点

特点：
1.每个表的结构都不一样。
2.每个表的数据也不一样，一般通过一列（主键/外键）关联。
3.所有表的并集是全量数据。

6.水平分库

6.1介绍

水平分库：以字段为依据，按照一定策略，将一个库的数据拆分到多个库中

6.2特点

特点：
1.每个库的表结构都一样。
2.每个库的数据都不一样。
3.所有库的并集是全量数据

7.水平分表

7.1介绍

水平分表：以字段为依据，按照一定策略，将一个表的数据拆分到多个表中

7.2特点

特点：
1.每个表的表结构都一样。
2.每个表的数据都不一样。
3.所有表的并集是全量数据。

8.实现技术

Mycat是采用java语言开发的开源的数据库中间件，支持Windows和Linux运行环境，下面介绍
MyCat的Linux中的环境搭建。我们需要在准备好的服务器中安装如下软件:

我们选择了是MyCat数据库中间件，通过MyCat中间件来完成分库分表操作。
MySQL
JDK
Mycat

9.分库分表原因

分表:
比如你单表都几千万数据了，单表数据量太大，会极大影响你的 sql执行的性能，到了后面 sql 可能就跑的很慢了。一般来说，单表到几百万的时候，性能就会相对差一些了，就得分表了。
分表就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。

分库:
分库就是你一个库一般我们经验而言，最多支撑到并发 2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒 1000 左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
这就是所谓的分库分表。

10.分库分表中间件及优点和缺点

比较常见的包括：
1.cobar
2.TDDL
3.atlas
4.sharding-jdbc
5.mycat

cobar

阿里 b2b 团队开发和开源的，属于 proxy 层方案。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。

TDDL

淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。

atlas

360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。

sharding-jdbc

当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。

mycat

基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。

11.如何对数据库如何进行垂直拆分或水平拆分

水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。

垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去**，然后**将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。

两种分库分表的方式：

1.一种是按照 range 来分，就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了。
range 来分，好处在于说，扩容的时候很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。
2.或者是按照某个字段hash一下均匀分散，这个较为常用。
hash 分发，好处在于说，可以平均分配每个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表