当数据库的数据量过大，大到一定的程度，我们就可以进行分库分表。那么基于什么原则，什么方法进行拆分，这就是本篇所要讲的。

不管是 IO 瓶颈还是 CPU 瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载的活跃连接数的阈值。

在业务 Service 来看， 就是可用数据库连接少甚至无连接可用，接下来就可以想象了（并发量、吞吐量、崩溃）。

IO 瓶颈：

CPU 瓶颈：

概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。

结果：

场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库的情况下。

分析：库多了，IO 和 CPU 的压力自然可以成倍缓解。

概念：以字段为依据，按照一定策略（hash、range 等），讲一个表中的数据拆分到多个表中。

结果：

场景：系统绝对并发量没有上来，只是单表的数据量太多，影响了 SQL 效率，加重了 CPU 负担，以至于成为瓶颈，可以考虑水平分表。

分析：单表的数据量少了，单次执行 SQL 执行效率高了，自然减轻了 CPU 的负担。

概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。

结果：

场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块的情况下。

分析：到这一步，基本上就可以服务化了。例如：随着业务的发展，一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。

再者，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表中（主表和扩展表）。

结果：

• 每个表的结构不一样；

• 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；

• 所有表的并集是全量数据。

场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大，以至于数据库缓存的数据行减少，查询时回去读磁盘数据产生大量随机读 IO，产生 IO 瓶颈。

分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能经常会查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表，这样更多的热点数据就能被缓存下来，进而减少了随机读 IO。

拆了之后，要想获取全部数据就需要关联两个表来取数据。但记住千万别用 Join，因为 Join 不仅会增加 CPU 负担并且会将两个表耦合在一起（必须在一个数据库实例上）。

关联数据应该在 Service 层进行，分别获取主表和扩展表的数据，然后用关联字段关联得到全部数据。

常用的分库分表工具如下：

各种工具的利弊自查。

分库分表能有效缓解单机和单表带来的性能瓶颈和压力，突破网络 IO、硬件资源、连接数的瓶颈，同时也带来一些问题，下面将描述这些问题和解决思路。

1）分布式事务

当更新内容同时存在于不同库找那个，不可避免会带来跨库事务问题。跨分片事务也是分布式事务，没有简单的方案，一般可使用“XA 协议”和“两阶段提交”处理。

分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间，导致事务在访问共享资源时发生冲突或死锁的概率增高。

随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平扩展的枷锁。

2）最终一致性

对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。

与事务在执行中发生错误立刻回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等。

切分之前，系统中很多列表和详情表的数据可以通过 Join 来完成，但是切分之后，数据可能分布在不同的节点上，此时 Join 带来的问题就比较麻烦了，考虑到性能，尽量避免使用 Join 查询。

解决的一些方法：

1）全局表

全局表，也可看做“数据字典表”，就是系统中所有模块都可能依赖的一些表，为了避免库 Join 查询，可以将这类表在每个数据库中都保存一份。这些数据通常很少修改，所以不必担心一致性的问题。

2）字段冗余

一种典型的反范式设计，利用空间换时间，为了性能而避免 Join 查询。

例如，订单表在保存 userId 的时候，也将 userName 也冗余的保存一份，这样查询订单详情顺表就可以查到用户名 userName，就不用查询买家 user 表了。

但这种方法适用场景也有限，比较适用依赖字段比较少的情况，而冗余字段的一致性也较难保证。

3）数据组装

在系统 Service 业务层面，分两次查询，第一次查询的结果集找出关联的数据 id，然后根据 id 发起器二次请求得到关联数据，最后将获得的结果进行字段组装。这是比较常用的方法。

4）ER 分片

关系型数据库中，如果已经确定了表之间的关联关系（如订单表和订单详情表），并且将那些存在关联关系的表记录存放在同一个分片上，那么就能较好地避免跨分片 Join 的问题。

可以在一个分片内进行 Join，在 1：1 或 1：n 的情况下，通常按照主表的 ID 进行主键切分。

跨节点多库进行查询时，会出现 limit 分页、order by 排序等问题。

分页需要按照指定字段进行排序，当排序字段就是分页字段时，通过分片规则就比较容易定位到指定的分片；当排序字段非分片字段时，就变得比较复杂。

需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。

最终返回给用户如下图：

上图只是取第一页的数据，对性能影响还不是很大。但是如果取得页数很大，情况就变得复杂的多。

因为各分片节点中的数据可能是随机的，为了排序的准确性，需要将所有节点的前N页数据都排序好做合并，最后再进行整体排序，这样的操作很耗费 CPU 和内存资源，所以页数越大，系统性能就会越差。

在使用 Max、Min、Sum、Count 之类的函数进行计算的时候，也需要先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总再次计算。

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库自生成 ID 无法保证全局唯一。

因此需要单独设计全局主键，避免跨库主键重复问题。这里有一些策略：

1）UUID

UUID 标准形式是 32 个 16 进制数字，分为 5 段，形式是 8-4-4-4-12 的 36 个字符。

UUID 是最简单的方案，本地生成，性能高，没有网络耗时，但是缺点明显，占用存储空间多。

另外作为主键建立索引和基于索引进行查询都存在性能问题，尤其是 InnoDb 引擎下，UUID 的无序性会导致索引位置频繁变动，导致分页。

2）结合数据库维护主键 ID 表

在数据库中建立 sequence 表：

stub 字段设置为唯一索引，同一 stub 值在 sequence 表中只有一条记录，可以同时为多张表生辰全局 ID。

使用 MyISAM 引擎而不是 InnoDb，已获得更高的性能。MyISAM 使用的是表锁，对表的读写是串行的，所以不用担心并发时两次读取同一个 ID。

当需要全局唯一的 ID 时，执行：

此方案较为简单，但缺点较为明显：存在单点问题，强依赖 DB，当 DB 异常时，整个系统不可用。配置主从可以增加可用性。另外性能瓶颈限制在单台 MySQL 的读写性能。

另有一种主键生成策略，类似 sequence 表方案，更好的解决了单点和性能瓶颈问题。

这一方案的整体思想是：建立 2 个以上的全局 ID 生成的服务器，每个服务器上只部署一个数据库，每个库有一张 sequence 表用于记录当前全局 ID。

表中增长的步长是库的数量，起始值依次错开，这样就能将 ID 的生成散列到各个数据库上。

这种方案将生成 ID 的压力均匀分布在两台机器上，同时提供了系统容错，第一台出现了错误，可以自动切换到第二台获取 ID。

但有几个缺点：系统添加机器，水平扩展较复杂；每次获取 ID 都要读取一次 DB，DB 的压力还是很大，只能通过堆机器来提升性能。

3）Snowflake 分布式自增 ID 算法

Twitter 的 Snowfalke 算法解决了分布式系统生成全局 ID 的需求，生成 64 位 Long 型数字。

组成部分如下：

当业务高速发展、面临性能和存储瓶颈时，才会考虑分片设计，此时就不可避免的需要考虑历史数据的迁移问题。

一般做法是先读出历史数据，然后按照指定的分片规则再将数据写入到各分片节点中。

此外还需要根据当前的数据量个 QPS，以及业务发展速度，进行容量规划，推算出大概需要多少分片（一般建议单个分片的单表数据量不超过 1000W）。

并不是所有表都需要切分，主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”，避免“过度设计”和“过早优化”。

分库分表之前，先尽力做力所能及的优化：升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后，在考虑分库分表。

这里的运维是指：

这里就不举例了，在实际业务中都可能会碰到，有些不经常访问或者更新频率低的字段应该从大表中分离出去。

随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。