MySQL 分库分表方案，总结的非常好！

 

前言

公司最近在搞服务分离，数据切分方面的东西，因为单张包裹表的数据量实在是太大，并且还在以每天60W的量增长。 之前了解过数据库的分库分表，读过几篇博文，但就只知道个模糊概念， 而且现在回想起来什么都是模模糊糊的。

今天看了一下午的数据库分库分表，看了很多文章，现在做个总结，“摘抄”下来。（但更期待后期的实操） 会从以下几个方面说起： 

第一部分：实际网站发展过程中面临的问题。 

第二部分：有哪几种切分方式，垂直和水平的区别和适用面。

第三部分：目前市面有的一些开源产品，技术，它们的优缺点是什么。

第四部分：可能是最重要的，为什么不建议水平分库分表！？这能让你能在规划前期谨慎的对待，规避掉切分造成的问题。

名词解释

库：database；表：table；分库分表：sharding

数据库架构演变

刚开始我们只用单机数据库就够了，随后面对越来越多的请求，我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver Replication）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展，所以更多的读请求不成问题。

但是当用户量级上来后，写请求越来越多，该怎么办？加一个Master是不能解决问题的， 因为数据要保存一致性，写操作需要2个master之间同步，相当于是重复了，而且更加复杂。

这时就需要用到分库分表（sharding），对写操作进行切分。

分库分表前的问题

任何问题都是太大或者太小的问题，我们这里面对的数据量太大的问题。

用户请求量太大

因为单服务器TPS，内存，IO都是有限的。 解决方法：分散请求到多个服务器上； 其实用户请求和执行一个sql查询是本质是一样的，都是请求一个资源，只是用户请求还会经过网关，路由，http服务器等。

单库太大

单个数据库处理能力有限；单库所在服务器上磁盘空间不足；单库上操作的IO瓶颈 解决方法：切分成更多更小的库

单表太大

CRUD都成问题；索引膨胀，查询超时 解决方法：切分成多个数据集更小的表。

分库分表的方式方法

一般就是垂直切分和水平切分，这是一种结果集描述的切分方式，是物理空间上的切分。 我们从面临的问题，开始解决，阐述： 首先是用户请求量太大，我们就堆机器搞定（这不是本文重点）。

然后是单个库太大，这时我们要看是因为表多而导致数据多，还是因为单张表里面的数据多。 如果是因为表多而数据多，使用垂直切分，根据业务切分成不同的库。

如果是因为单张表的数据量太大，这时要用水平切分，即把表的数据按某种规则切分成多张表，甚至多个库上的多张表。 分库分表的顺序应该是先垂直分，后水平分。 因为垂直分更简单，更符合我们处理现实世界问题的方式。

垂直拆分

1. 垂直分表

   也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。 一般是针对那种几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。

2. 垂直分库

   垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Producet一个库，订单Order一个库。 切分后，要放在多个服务器上，而不是一个服务器上。为什么？ 我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

   数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。 数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。 数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

水平拆分

1. 水平分表

   针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。不建议采用。

2. 水平分库分表

   将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

3. 水平分库分表切分规则

1. RANGE

   从0到10000一个表，10001到20000一个表；

2. HASH取模

   一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。

3. 地理区域

   比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。

4. 时间

   按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后面临的问题

事务支持

分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

多库结果集合并（group by，order by）

TODO

跨库join

TODO 分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。 粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。

分库分表方案产品

目前市面上的分库分表中间件相对较多，其中基于代理方式的有MySQL Proxy和Amoeba， 基于Hibernate框架的是Hibernate Shards，基于jdbc的有当当sharding-jdbc， 基于mybatis的类似maven插件式的有蘑菇街的蘑菇街TSharding， 通过重写spring的ibatis template类的Cobar Client。

还有一些大公司的开源产品：

为什么不建议分库分表

下面

MySQL分库分表方案

翻译一个stackoverflow上的问答，关于分库分表的缺点的，原文链接: 

MySQL sharding approaches? https://stackoverflow.com/questions/5541421/mysql-sharding-approaches

问题：

什么是最好的MySQL分库分表方案？我想到的有：

1、应用层切分？

2、MySQL代理层切分？

3、提供查找数据库分片的中心服务？

你们知道任何这方面有趣的项目或者工具吗？

回答：

最好的切分MySQL的方式就是：除非万不得已，否则不要去干它。

当你写一个应用时，你通常都想要最快的开发速度。只有必要时，你才开始优化延时，提高吞吐量，

你切分数据库的原因无非因为数据库的读或者写：

• 数据库写

  写操作永久的超过了服务器的磁盘负载；太多写入导致副本同步永远的落后了。

• 数据库读

  读取到的数据量太大以至于称爆内存；并且大多数读操作开始直击磁盘而不是从内存中读取数据。

只有这时，你才需要考虑做数据库切分。

当你开始切分后，你开始以下面几种方式支付代价：

你的SQL语句不再是声明式的（declarative）

一般的，你用SQL语句告诉数据库你要什么数据，然后让优化器优化SQL，并将SQL转化成数据获取程序。

这很棒，因为它非常灵活，而且写这些转化程序很无聊，严重影响开发速度。

分布式环境下，你将A节点的表和B节点的表进行join，甚至有些表的数据大到超过一个节点，在A节点和B节点将数据join起来,然后将B节点和C节点join后的数据再次聚合。你开始写单方面的hash应用程序来解决这个问题（或者你可以再造MySQL的集群），这表示结果你得到一大堆的非声明式的SQL，而且让程序以一种面向过程的方式开始工作。

你招致了大量的网络延时

一般的，一条SQL查询语句可以本地解决并且通过优化器以最小的耗时解决这个查询问题。

在分布式环境下，查询语句必须要通过KV映射，访问多个网络节点（希望是批量访问，而不是每个Key都来一次网络往返），或者将WHERE条件放在他们将被执行的节点上。

但是即使在最好的情况下，涉及到多个网络访问都会更加复杂。特别是MySQL的优化器完全不知道网络延时的情况。

你失去了SQL的许多强大能力

好吧，这或许没那么重要，但是外键约束，其他保证数据完整性的SQL机制，对于跨多个节点是无能为力的。

 

MySQL没有API保证异步查询返回顺序结果

当相同类型的数据存放在多个节点上（比如用户数据存放在A,B,C节点上），水平查询需要访问所有节点，数据访问时间直接因以节点数线性增长。除非多个节点是以并行方式访问，然后再以Map-Reduce的方式聚合。

前提是需要提供异步通信的API，但这并不存在于MySQL提供的功能中。可选的方案是在子进程中增加很多的forking和连接。

总结

当你开始做数据库分库分表，数据结构和网络拓扑明显影响到应用的性能。 

为了运行良好，你的应用需要当心这些事情，所以只有应用层的切分才有意义。

如果需要自动切分，问题会更多（比如决定那个节点的那个列作为hash主键），或者

你想要手动进行切分，xyz用户去这个主库上，abc去和def去到那个主库上。

业务功能上的切分有些好处，如果做对了，这对绝大部分开发人员是透明的。因为所有相关的表都存放在本地。 

这让程序的透明性可以从声明式的SQL中尽量受益，并且有更少的网络延时，因为跨节点的网络访问被保持到最小化。

业务功能上的切分的缺点是：它不能准许单个表的数据膨胀过大，这需要设计者的特别注意。

业务功能切分的好处是：针对一个并没有太多改变的代码库，它相对而言非常简单。 

Booking.com在过去几年进行过几次业务功能上的分库分表，并且一直工作的很好。