分库分表理论知识

一、前言

当一张表的数据达到几千万时，查询一次所花的时间会变得很长，系统效率会下降。Oracle 官方推荐单表容量为 500w 以下为最佳状态。

但单表或单库达到性能瓶颈时，就需要对数据库进行拆分，数据库拆分又分为：

垂直拆分
水平拆分

二、垂直拆分

垂直拆分可以分为：垂直分表 和 垂直分库。

垂直分表

概念：把一个表的多个字段分别拆成多个表，一般按字段的访问频次拆分，经常访问的字段一个表，不经常访问的字段一个表。减少布不必要的字段查询，提高数据库性能。

如图：

垂直分库

概念：就是根据业务耦合性，将关联度低的不同表存储在不同的数据库中。做法与大系统拆分成多个小系统类似，按业务类型进行独立划分。与 微服务划分 的做法类似。每个微服务使用单独的一个数据库。

如图：

说明：

业务数据量小的情况下，只有一个数据库，所有的表都在这个库里。

业务扩展，数据量增加，单体服务转变为微服务治理。要将之前的库按业务类型拆分成多个库。每个微服务对应一个库。

垂直拆分优缺点

优点：

解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分能一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈

缺点：

分库后无法Join查询，只能通过接口聚合方式解决，提高了开发的复杂度
分库后分布式事务问题处理复杂
依然会存在单表数据量过大的问题（需要进行水平拆分）

三、水平拆分

当一个应用难以再通过细粒度的垂直拆分或拆分之后数据量行数过大，存在单库、单表读写及存储性能瓶颈，这时就需要进行水平拆分。

水平拆分也可以分为：水平分库 和 水平分表。

水平分库

原因：上面虽然已经把商品库分成3个库，但是随着业务的增加，系统的QPS过高，数据库响应速度来不及。但系统QPS达到瓶颈时就要考虑分库。

如图：

水平分表

原因：一般我们一张表的数据不要超过 500w，如果表数据超过 500w，并且还在不断增加数据，那就可以考虑分表。

如图：

水平拆分优缺点

优点：

避免单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
应用端改造较小，不需要拆分业务模块

缺点：

跨分片的事务一致性难以保证
跨库的Join关联查询性能较差
数据多次扩展难度和维护量极大

四、数据分片规则

当我们考虑去水平拆分表时，需要将一张表水平拆分成多张表，这就涉及到数据分片的规则，比较常见的有：Hash取模分表、数值Range分表、一致性Hash算法分表。

Hash取模分表

概念：一般采用Hash取模的拆分方式，例如：假设按 goods_id 分4张表。（goods_id%4 取整数确定表）

优点：

数据分片相对均匀，不容易出现热点和并发访问的瓶颈

缺点：

后期分片集群扩容时，需要迁移旧的数据很难。
容易面临跨分片查询的复杂问题。比如上例中，如果频繁用到的查询条件中不带goods_id时，将会导致无法定位数据库，从而需要同时向4个库发起查询，再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。

数值Range分表

概念：按照时间区间或ID区间来拆分。比如：将goods_id为1-1000的记录分到第一个表，1001-2000的分到第二个表，以此类推。

如图：

优点：

单表大小可控
天然便于水平扩展，后期如果想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片数据进行迁移
使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题

缺点：

热点数据成为性能瓶颈（例如按时间进行分片，有些分片存储醉经时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询）

一致性Hash算法

一致性Hash算法可以很好的 解决因为Hash取模而产生的分片集群扩容时，需要迁移旧的数据的难题。

参考：一致性Hash算法详解 - 知乎 (zhihu.com)

五、分库分表带来的问题

==在非必要的情况下，能不分就不分==

因为分库分表会引入新的问题，任何单体系统拆分成多个都会提高系统维护的复杂度，破坏整体性。

分布式事务问题

使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求决定。

参考：分库分表导致的分布式事务及其解决方案

跨节点关联查询 Join 问题

切分之前，我们可以通过Join来完成。而切分之后，数据可能分布在不同的节点上，此时 Join 带来的问题就比较麻烦了，考虑到性能，尽量避免使用 Join 查询。

解决方案：

全局表

全局表，也可以看做是 数据字典表，就是系统中所有模块都可以依赖的一些表，为了避免跨库 Join 查询，可以将这类表

字段冗余

利用空间换时间，为了性能而避免 Join 查询。例如：订单表保存 userId 时，也将 userName 冗余保存一份，这样查询订单详情时就不需要再去查询 买家user表了。

数据组装

在系统层面，分两次查询。第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。

跨节点分页、排序、函数问题

跨节点多库进行查询时，会出现Limit分页、Order by 排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。