百亿数据分库分表核心流程详解

前言

俗话说：面试造火箭，入职拧螺丝。尽管99.99%的业务都不需要用到分库分表，但是分库分表还是频繁出现在大厂的面试中。

分库分表涉及到的内容非常多，有很多细节，如果在面试中被问到了，既是挑战，也是机会，如果你能回答好的话，会给你的面试加很多分。

由于业务量的关系，绝大部分同学都很难有实际分库分表的机会，因此很多同学在碰到这个问题时很容易懵逼。

因此今天跟大家分享一下分库分表的相关知识，本文内容源于实际高并发+海量数据业务下的实战和个人的思考总结。

什么是分库分表

分表

分表指的是在数据库数量不变的情况下，对数据库里面的表进行拆分。

例如我们将SPU表从一张拆成四张。

分库

分库指的是在表数量不变的情况下对数据库进行拆分。

例如我们本来有一个库里面放了两张表，一张是SPU表，一张是SKU表。我们将这两张表拆到两个不同的库里面去。

分库分表

也就是数据库的数量，还有表的数量都发生变更。

例如我们有一个数据库里面本来有一张SPU表。我们将这个SPU表拆成四张表，并且放在两个数据库里面。

拆分方式

当前主要的拆分方式有两种：水平拆分和垂直拆分。

水平拆分就是从左往右横着切，垂直拆分就是从上往下竖着切。当然具体切几刀，这个要看具体的业务需求。

水平拆分

水平拆分指的是在整个表数据结构不发生变更的情况下，将一张表的数据拆分成多张表。因为当单张表的数据量越来越大时，这张表的查询跟写入性能也会相应的变得越来越慢。

因此这个时候我们可以将单张表拆分成多张表，从而让每张表的数据量都变小，从而可以提供更好的读写性能。

垂直拆分

垂直拆分指的是将本来放在一张表的字段拆分到多张表中。

例如在这个例子中，我们将pic这个字段单独拆分出来，然后剩下的三个字段还保留在原表里面。

这种场景主要是因为在业务的初期，为了业务的快速发展，我们将商品的所有字段都放在一张表里面。但是随着后面的业务的发展，我们发现这个pic字段可能变得越来越大，从而影响到我们商品的基本信息的查询性能。因此这个时候我们可以将这个pic字段单独拆分出去。

当然这个pic字段拆分出去之后，它应该要存储这个原来这个商品的这个id。

为什么需要分库分表

因为单台MySQL服务器的硬件资源是有限的，随着业务的不断发展，请求量和数据量会不断增加，数据库的压力会越来越大，到了某一时刻，数据库的读写性能可能会开始下降，这个时候数据库就成为请求链路中的瓶颈。

此时可能就需要我们去对数据库进行优化，业务初期我们可能会使用增加索引、优化索引、读写分离、增加从库等手段来进行优化，但是随着数据量的不断增大，这些优化手段的效果会变得越来越小，此时可能就需要使用分库分表来进行优化，对数据进行切分，将单库和单表的数据量控制在合理的范围内，以保证数据库可以提供高效的读写能力。

何时需要分库分表

总体来说：当性能出现瓶颈，并且其他优化手段无法很好的解决的时候。

我们这边必须首先明确分库分表一般是作为最终的解决手段，我们会优先使用其他的方法来进行优化。常见的优化手段有增加索引、优化索引、读写分离、增加数据库的从库等等。当我们使用这些手段都无法解决的时候，就需要来考虑分库分表。

单表出现瓶颈：

• 单表数据量较大，导致读写性能较慢。

单库出现瓶颈：

• CPU压力过大（busy、load过高），导致读写性能较慢。

• 内存不足（缓存池命中率较低、磁盘读写IOPS过高），导致读写性能较慢。

• 磁盘空间不足，导致无法正常写入数据。

• 网络带宽不足，导致读写性能较慢。

单表超过千万级，就需要进行分库分表？

这种说法不完全准确。因为有的表它本身的结构比较简单，字段也比较少。这种表可能即使数据量已经超过了亿级，整体的读写性能也是比较高的。而有的表如果整体的结构比较复杂，字段本身也比较大，可能只是百万级，整体的性能已经比较慢了。所以这个还是得结合自己的业务情况来进行分析。这个千万级只能是作为一个参考。

如何选择分库分表

只分表：

• 单表数据量较大，单表读写性能出现瓶颈。

• 经过评估单库的容量和性能可以支撑未来几年的增长。

只分库：

• 数据库（读）写压力较大，数据库出现存储性能瓶颈。

分库分表：

• 单表数据量较大，单表读写性能出现瓶颈。

• 数据库（读）写压力较大，数据库出现存储性能瓶颈。

注意点：

我们在进行选择的时候&#x