面试官：分库分表，真的有必要吗？

关于数据库分库分表的面试题已经是烂大街了，面经小册各路神仙的经验分享也是不绝于耳。当然现有的技术解决方案已经是很成熟了。

但是想要使用的得心应手，首先应该搞清楚三个问题？

• 为什么使用分库分表？

• 何时使用分库分表？

• 如何分库分表？

为什么使用分库分表？

答案很简单：当数据库出现性能瓶颈。顾名思义就是数据库扛不住了。

数据库出现瓶颈，对外表现有以下几个方面？

1. 高并发场景下，大量请求阻塞，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。

2. SQL 操作变慢（慢 SQL 增多）如果数据库中存在一张上亿数据量的表，一条 SQL 没有命中索引会全表扫描，这个查询耗时会非常久。

3. 随着业务流量变大存储出现问题，单库数据量越来越大，给存储造成巨大压力。

从机器角度，性能瓶颈不外乎就是 CPU、磁盘、内存、网络这些，要解决性能瓶颈最简单粗暴的方式就是提升机器性能，但是通过这种方式投入产出比往往不高，也不划算，所以重点还是要从软件层面去解决问题。

数据库相关优化方案

数据库优化方案很多，主要分为两大类：软件层面、硬件层面。

• 软件层面包括：SQL 调优、表结构优化、读写分离、数据库集群、分库分表等；

• 硬件层面主要是增加机器性能。

分库分表其实不是数据库优化方案的最终解决办法，一般来说说能用优化 SQL、表结构优化、读写分离等手段解决问题，就不要分库分表，因为分库分表会带来更多需要解决的问题，比如说分布式事务，查询难度增大等。

何时使用分库分表？

什么时候我们才会选择分库分表？前面已经说了，除了分库分表以外那些软件手段搞不定的时候，我们才会选择分库分表。

我们心中可能会有这些疑问？

1. 使用分库分表，我们的评判依据是什么？

2. 一张表存储了多少数据的时候，才需要考虑分库分表？

3. 数据增长速度很快，每天产生多少数据，才需要考虑做分库分表？

阿里巴巴开发手册有推荐的思路：单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

注意：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

如何分库分表？

当前针对分库分表有很多解决方案。这里分两个方面来展开说说：分库 和 分表。

分库

很多项目前期为了快速迭代，多个应用公用一套数据库，随着业务量增加，系统访问压力增大，系统拆分就势在必行。

为了保证业务平滑，系统架构重构也是分了几个阶段进行。

多应用单数据库

第一个阶段将商城系统单体架构按照功能模块拆分为子服务，比如：Portal 服务、用户服务、订单服务、库存服务等。

多应用单数据库如上图，多个服务共享一个数据库，这样做的目的是底层数据库访问逻辑可以不用动，将影响降到最低。

多应用多数据库

随着业务推广力度加大，数据库终于成为了瓶颈，这个时候多个服务共享一个数据库基本不可行了。我们需要将每个服务相关的表拆出来单独建立一个数据库，这其实就是“分库”了。

单数据库的能够支撑的并发量是有限的，拆成多个库可以使服务间不用竞争，提升服务的性能。

从一个大的数据中分出多个小的数据库，每个服务都对应一个数据库，这就是系统发展到一定阶段必要要做的“分库”操作。

分表

说完了分库，那什么时候才会分表呢？

如果系统处于高速发展阶段，拿商城系统来说，一天下单量可能几十万，那数据库中的订单表增长就特别快，增长到一定阶段数据库查询效率就会出现明显下降。

因此当表数据增长过快，根据阿里巴巴开发规范中超过 500w 的数据就要考虑分表了，当然这只是一个经验值，具体要不要分表还要看业务考虑未来三年的一个业务增量。

如何分表？

分表有几个维度，一是水平切分和垂直切分，二是单库内分表和多库内分表。

水平拆分和垂直拆分

拿商品表来说，表中分为几类属性：一类是基础属性，例如：商品名称、通用名，商品编码等信息。二类是规格属性：尺寸、型号等信息。三类是拓展属性：描述商品特征的一些属性。我们可以将其拆分为基础信息表、拓展属性表、属性信息表等。这几张表结构不同并且相互独立。但是从这个角度没有解决因为数据量过大而带来的性能问题，因此我们还需要继续做水平拆分。

水平拆分表的方法很多种，比如说 1w 条数据，我们拆分为两个表，id 为基数的放在 user1，id 为偶数的放在 user2 中，这样的拆分方式就是水平拆分。

其他水平拆分的方式也很多，除了上面按照 id 来拆分，还可以按照时间维度拆分，比如订单表，可以按照每日、每月等进行拆分。

• 每日表：只存储当天你的数据。

• 每月表：可以起一个定时任务将前一天的数据全部迁移到当月表。

• 历史表：同样可以用定时任务把时间超过 30 天的数据迁移到 history 表。

总结一下水平拆分和垂直拆分的特点：

• 垂直切分：基于表或者字段划分，表结构不同。

• 水平拆分：基于数据划分，表结构相同，数据不同。根据表中字段的某一列特性，分而治之。

水平拆分也分两种拆分方式。单库内拆分和多库内拆分

单库内拆分和多库内拆分

拿针对用户表的拆分来举例，之前的单个用户表按照某种规则拆分为多个子表，多个子表存在于同一数据库中。比如下面用户表拆分为用户 1 表、用户 2 表。

单库内拆分是在一个数据库中，将一张表拆分为多个子表，一定程度上可以解决单表查询的性能问题，但是也会遇到另外一个问题：但数据库的数据瓶颈。

所以在行业内更多的将子表拆分到多个数据库中，如下图，用户表拆分为 4 个子表，4 个子表分两批存在两个不同的数据库中，根据一定的规则进行路由。

多库拆分用一句话概括：主要是为了减少单张表数据量大小，解决单表数据量过大带来的性能问题。

但是分库分表也带来许多问题。

分库分表带来的问题

既然分库分表方案那么好，那我们是不是在项目初期就应该采用这种方案呢？莫慌，虽然分库分表解决了很多性能问题，但是同时也给系统带来了很多复杂性。下面我展开说说

1. 跨库关联查询

之前单体项目，我们想查询一些数据，无脑 join 就好了，只要数据模型设计没啥问题，关联查询起来其实还是很简单的。现在不一样了，分库分表后的数据可能不在一个数据库，那我们如何关联查询呢？

下面推荐几种方式去解决这个问题：

1. 字段冗余：把需要关联的字段放到主表中，避免 join 操作，但是关联字段更新，也会引发冗余字段的更新；

2. 数据抽象：通过 ETL 等将数据汇总聚合，生成新的表；

3. 全局表：一般是一些基础表可以在每个数据库都放一份；

4. 应用层组装：将基础数据查出来，通过应用程序计算组装；

5. 同特征的数据在一张表：举个例子：同一个用户的数据在同一个库中，比如说我们对订单按照用户 id 进行分表，订单主表、订单拓展信息表、跟订单有关联查询的表都按照用户 id 进行分表，那么同一个用户的订单数据肯定在同一个数据库中，订单维度的关联查询就不存在跨库的问题了。

2. 分布式事务

单数据库我们可以用本地事务搞定，使用多数据库就只能通过分布式事务解决了。

常用的解决方案有：基于可靠消息（MQ）的最终一致性方案、二段式提交（XA）、柔性事务。

当然分布式事务相关开源项目推荐两个：Seata 、TX-LCN

比较推荐 Seata，阿里出品、大厂加持、如果需要企业级版本支持也是有的。

3. 排序、分表、函数计算问题

使用 SQL 时，order by 、limit 等关键字需要特殊处理，一般都是采用数据分片的思路：现在每个分片路由上执行函数、然后将每个分片路由的结果汇总再计算，然后得出最终结果。

开源的解决方案当然也有不少，比较推荐 shardingsphere，无论是基于 client 或者 基于数据库 proxy 的都有支持。

4. 分布式 ID

既然分库分表了，主键 id 已经不能唯一确定我们的业务数据了，随之而来的就是分布式 id，顾名思义就是在多个数据库多张表中唯一确定的 ID。

常见的分布式 Id 解决方案有：

1. UUID

2. 基于全局数据库自增的 ID 表

3. 基于 Redis 缓存生成全局 ID

4. 雪花算法（Snowflake）

5. 百度 uid-generator（雪花算法的变种）

6. 美团 Leaf（雪花算法的变种）

7. 滴滴 Tinyid

这些解决方案后面有专门的文章去介绍，这里不过多展开。

5. 多数据源

分库分表之后可能面临从多个数据库中获取数据，一般的解决方案有，基于 client 适配 和 基于 proxy 适配。

比较成熟并且常用的中间件有：

• shardingsphere（apache 顶级项目相当成熟，文档完善）

• MyCat （社区不太活跃、不推荐）

总结

如果遇到数据库问题，建议不要着急分库分表。原则是：能不分库分表就不要做。先看下能否通过常规优化手段解决问题。

如上所述，引入分库分表虽然可以解决数据库瓶颈问题，但是也给系统带来巨大的复杂性，不是非必须不要使用。设计系统我们一向要本着高可拓展去设计，但是不要过度设计和超前设计。适合当前系统的设计才是最好的。

作者：爪哇干货分享

链接：https://juejin.cn/post/7186448714779590711

来源：稀土掘金