分库分表已经是互联网当中一个常见的名词了，那么究竟如何做分库分表呢？

一、首先，什么是分库分表

顾名思义

分库：即将原本一个库的数据拆分成多个库数据库存储。

分表：将原本一张表存放的数据拆成多张表存储。

二、为什么要分库分表呢

分库分表的出现可以从以下几个方面来看：

1.垂直分库

现在互联网服务化或者微服务这个概念已经很普及了，如果所有的微服务用的还是同一个库，比如订单、商品用的还是一个库，那如果这个库挂了，那么订单跟商品两个服务都挂了。

为了提高系统可用性，所以此时我们需要做订单跟商品库的拆分，并且此时两个库所在的实例应该是不同的，此时我们可以将这种方式成为垂直分库。

2.垂直分表

比如一张表100个字段，但是只有20个字段是经常要用的，这时完全可以将这20个字段抽出来作为一张主表。

以mysql为例，这样数据库在存储数据的时候一页存储的数据量会更多，磁盘按块读取，则一次IO获取的数据更多，在只用到主表数据的情况下，理论上会更快，此时可以称为垂直分表。

例如订单表的简单拆分如下：

3.水平分表

但是当碰到单表数据很多的情况，比如一张订单表1亿条数据，这显然是不合理的，此时我们需要将单表的数据拆分到多张表当中，比如分为16张表，此时可以称为水平分表。

4.水平分库

大部分场景下，我们做了垂直分库就行了，但是如果此时数据的操作非常频繁，我们仅仅在同一个库中对表进行了拆分，还是远远不够的。

数据库单个实例支持的TPS是有上限的，比如腾讯云mysql单个实例8H32G配置的情况下，读写比4:1，仅能支持3600的TPS，48H488G的情形下最高可支持到46000的TPS。

如果整个系统需要支持更高的TPS，则需要更多的实例，将数据分散到各个不同的实例上，此时称为水平分库。

当需要支持更高的QPS，那此时还需要给每个库加上读库。

总结一下：其实就是为了系统的高可用、高并发。

三、分库分表如何做

常见的组合：

1.垂直分库+不分表

2.不分库+水平分表

3.垂直分库+水平分表

4.垂直分库+水平分库分表

这是一个跟业务强相关的问题，比如我的系统希望能支持10W的TPS，那我起码需要5台24H244G的腾讯云mysql实例，至于具体分多少个库多少张表则取决于我的数据量大小。

选择合适的分表数量，比如我的系统目标是能支撑100亿的数据存储，以单张表1000W的数据计算，总计需要1000张表，如果一个库128张表，则可以分8个库。

选择合适的分片字段，比如订单可以按照订单号来分表，但是订单号必须是全局唯一的。

四、分库分表之后的问题

1.id：

此时数据库的自增id不能作为表之间的关联字段，如果跟外部的表有关联，在保留自增id的基础上，我们需要增加全局唯一id字段。

全局唯一id常见的生成方式有uuid、雪花算法、数据库生成、redis自增等等。

2.数据倾斜：

如果分片字段选得不合理，可能会出现大部分数据落到某一个库或者某一张表里，比如订单表如果按照卖家进行分库分表，那么极有可能某个大商家的订单数太多全部分到一张表上导致大表的产生。

所以一般会选择一个均匀的字段，比如订单号来分表，此时的订单编号必须是跟商家id是没有关系的，比如按照订单号后四位，后四位必须是随机或者自增的号码。

3.此时又会产生新的问题，买家如何获取自己的订单列表？卖家如何查看所有买家的订单列表呢？

此时我们可以建立索引表：建立一张以买家id为分片字段的买家索引表，此时买家的订单列表先通过索引表获取订单号，然后通过订单号去查询订单表，同理卖家可以建立卖家纬度的索引表。

4.此时新的问题产生了：如何解决事务的问题？

同样是一个分场景的问题，以刚才的订单表举例，买家纬度的索引表因为实时性要求很高，所以可以与订单表放入同一个事务中，插入一条订单数据的同时，同步往买家索引表插入一条数据。

而卖家索引表的实时性要求稍低，则可以以异步的方式插入卖家索引表，并且添加补偿对账机制，以最终一致性的方式保证订单表与卖家索引表的数据一致性。

或者卖家端的查询可以使用检索引擎来解决，比如将订单数据放入ES当中，在检索引擎中做搜索后得到订单号，然后通过订单号去订单表查询订单数据。

5.扩容：

当最初设计的系统已经不能满足现有系统体量的时候，这个时候必然需要扩容，扩容又会涉及到数据的迁移，这个跟自身的业务有关系，常见的有停服迁移、从库升级、双写等等，这个比较多，可以单独拉出来说很久了。

总结：一切脱离实际的设计都是耍流氓，只有结合自身业务的方案才是最好的。