（面经总结）一篇文章带你整理面试中数据库分库分表的相关知识点

一、为什么要进行数据库分库分表？

主要是为了提升数据库的性能，因为当数据库中的数据量达到1000w或者100G以后，由于查询维度比较多，此时像添加优化索引之类的操作对于数据库的性能提升很小，所系需要对其进行分库分表，目的就是减小数据库的负担，将数据分散到多个数据库中，提升性能。

分库分表有垂直切分和水平切分两种

二、垂直切分

垂直分库：将表按照功能模块、关系密切程度划分并部署到不同的库中。

例如，我们会创建定义数据库workDB、商品数据库payDB、用户数据库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等，如图7-6所示。

垂直分表：是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。

优点：

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

缺点：

1-部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
2-分布式事务处理复杂
3-依然存在单表数据量过大的问题（需要水平切分）

三、水平切分

分库分表：是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。

库内分表：只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。

优点：

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

缺点：

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

三、水平切分的方法

水平分表相比垂直分表，会引入更多的复杂性，例如要求全局唯一的数据id该如何处理

1. 主键自增

以最常见的用户 ID 为例，可以按照 1000000 的范围大小进行分段，1 ~ 999999 放到表 1中，
1000000 ~ 1999999 放到表2中，以此类推。

复杂点：分段大小的选取。分段太小会导致切分后子表数量过多，增加维护复杂度；分段太大可能会
导致单表依然存在性能问题，一般建议分段大小在 100 万至 2000 万之间，具体需要根据业务选取合适
的分段大小。

优点：可以随着数据的增加平滑地扩充新的表。例如，现在的用户是 100 万，如果增加到 1000 万，
只需要增加新的表就可以了，原有的数据不需要动。

缺点：分布不均匀。假如按照 1000 万来进行分表，有可能某个分段实际存储的数据量只有 1 条，而
另外一个分段实际存储的数据量有 1000 万条。

2. 哈希取模

同样以用户 ID 为例，假如我们一开始就规划了 10 个数据库表，可以简单地用 user_id % 10 的值来
表示数据所属的数据库表编号，ID 为 985 的用户放到编号为 5 的子表中，ID 为 10086 的用户放到编号
为 6 的子表中。

复杂点：初始表数量的确定。表数量太多维护比较麻烦，表数量太少又可能导致单表性能存在问题。

优点：表分布比较均匀。

缺点：扩充新的表很麻烦，所有数据都要重分布。

3. 雪花算法

雪花算法是由Twitter公布的分布式主键生成算法，它能够保证不同表的主键的不重复性，以及相同表的
主键的有序性。

核心思想：
长度共64bit（一个long型）。

首先是一个符号位，1bit标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负
数是1，所以id一般是正数，最高位是0。

41bit时间截(毫秒级)，存储的是时间截的差值（当前时间截 - 开始时间截)，结果约等于69.73年。

10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID，可以部署在1024个节点）。

12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID）。

优点：整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞，并且效率较高。