还在为MySQL如何分库分表烦恼么？不妨看看这个思路

1.背景

        作为软件开发人员也许很少去考虑MySQL是应该如何分库分表，通常自己安装一个MySQL或拿到运维、DBA分配的数据库，就开始撸代码了，这样虽好可以让我们快速去实现业务逻辑，但也会存在一些问题的隐患。就比如：运维或DBA通常啊对业务不太清楚，他们分配的数据库就能满足业务的需要么？或者我们自己搭建的一个单节点开发环境的MySQL就能满足我们要开发的业务需要么？  通常企业内部员工使用的系统还能应付，如果稍微使用人群一多这样的MySQL就不能满足业务场景了，我们需要调整数据库架构，以满足业务数据的读取、写入性能要求，那么如何选择分库分表的方案？

2.问题分析

        并不是所有系统都需要分库分表，就比如一个简单的员工请假系统，确实不需要分库分表。但是如果是对于数据量大，还伴随着高并发的情况下，我们的数据库方案就需要去考虑使用分库分表方案以支撑系统的整体性能。那么如何进行分库分表呢？数据库的分库分表其实也有不同的方案进行选择，没有一套万能的公式可以套用。

        分库分表方案重点是以业务为向导，以业务的真实情况去选取合适的分库分表方案，上面这种情况是对于已经有业务支撑的，我们需要将这些业务电子化，其实思路比较明确。

        另外一种情况就是新开业务（预计大数据和高并发的系统），还没有业务支撑，我们应该选取怎么的数据库方案呢？其实这一点我认为，通常情况下系统查询量是远远大于写入量的，我们可以从最简单的读写分离入手，后期在根据业务变化去调整数据库分库分表（要求我们有比较强的设计能力和编码规范）。

        分库分表的原则：分库分表的顺序应该是先垂直分，后水平分。其实垂直分就相当于建立多个微服务的思路是一致的（表分到不同的库，以不同的服务提供出来），可以通过水平扩展来提升系统性能。水平分是一种对代码是有侵入的扩展方式，容易造成后期再次进行拆分时数据迁移困难。接下来我就分享几种以业务驱动的分库分表方案

3.方案介绍

        方案一：读写分离

                如果写少读多，那么可以采用数据库主从库：多个从库副本负责数据的读取，主库负责写，从库从主库同步更新数据，保持数据一致。架构是设计上就是数据库主从同步，从库可以水平扩展，以应对更多的读的请求（如果用户请求量太大，可以通过负载均衡将请求分散到多个从节点数据库进行查询）。

        方案二：单库太大，数据库切分

                以应对单库数据量太大，也就是单个数据库中数据表交多，如何将数据库进行切分呢？方法还有多个，我觉得比较容易实施的有两种方案，第一种方案、垂直分库：把一个数据库的不同表放到不同的数据库里面去。针对一个系统中的不同业务进行拆分，比如User一个库，商品一个库，订单一个库。切分后，要放在多个服务器上。第二种方案，水平分库：用户请求过来，根据用户名或用户的ID进行Hash取模，根据不同的取模结果，将数据落入对应的数据库中。

        方案三：单表太大，数据表切分

                单表数据太大，有人就说既然是为了应对查询，那么就在这个大表中建立索引，其实不然，如果单表数据量太大，建立索引不仅不能提升查询效率，反而会导致索引膨胀，导致查询超时，可行的方案就是将其拆分为多个相同的小表。方法1、垂直分表：也就是“大表拆小表”。一般是表中的字段较多，将不常用的，数据较大，长度较长的拆分到“扩展表”。方法2、水平拆分表：针对数据量巨大的单张表，按照某种规则（RANGE， HASH 取模等），切分到多张表里面去。但是这些表还是在同一个库中，所以库级别的数据库IO瓶颈无法避免。不建议采用。方法3、水平分库分表：将单张表的数据切分到多个服务器上去，每个服务器具有相应的库和表，只是表中数据集和不同。它能有效缓解单机和单库的性能瓶颈和压力，突破单机IO、连接数、硬件资源等瓶颈。

4.难点分析：

        垂直分库分表我们就先不讨论了，因为是对代码无侵入的可以通过调整负载或路由的方式进行实现。反而更有技术难度的，更难维护的水平拆分才具有挑战性，这里将我水平拆分的原则与大家进行分享

水平分库分表切分规则：

    第一、RANGE， 比如： 0~10000一个表，100001~20000一个表

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

    第三、地理区域，比如按照华东、华南来区分业务

    第四、时间，按照时间切分，比如将6个月前，甚至一年前的数据切出去放到另外一张表，因为随着时间流逝，这些表的数据被查询的概率变小。

5.分库分表后面临的问题：

    第一、分布式 事务支持

        当然目前支持的分布式事务其实可以一定程度的满足事务的要求分布式事务CAP的相关要求

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

        这个一般不在业务系统进行合并聚合查询分析，而是通过数据中台（微服务中台）双中台，将业务数据库的数据抽取的数据平台上面来，在数据平台上面机型聚合和分组查询

6.分库分表方案产品：

        垂直分库最主要是采用微服务架构（也是主流），其他的分库分表中间件相对较多，其中基于代理方式的有 MySQL Proxy 和 Amoeba， 基于Hibernate 框架的是 Hibernate Shards， 基于jdbc的有sharding-jdbc， 基于mybatis的有 蘑菇街 TSharding，通过重写spring 的 ibatis template 类的 的 Cobar Client

7.总结一下

        分库分表，首先考虑垂直拆分也就是使用微服务架构，其次，再去考虑水平拆分，因为水平拆分（水平拆分，对后期维护是一种挑战，首次方案的制定对后期扩展也是一种挑战）。