对于关系型数据库MySQL-如何选择分库分表方案

MySQL分库分表相关系列：MySQL相关目录

---

该如何选择分库分表方案

大型网站用户数和数据库规模急剧上升，关系型数据库常见的性能瓶颈主要体现在两点：

• 一是大量的并发读写操作，导致单库出现负载压力过大；（并发量大，数据库连接资源不足问题，磁盘IO的性能瓶颈问题）
• 二是单表存储数据量过大，导致查询效率低下。（单表数据量太大，sql语句查询数据时，即使走了索引也非常耗时问题。此外还有消耗cpu资源问题）

随着网站的业务不断扩展，数据不断增加，用户越来越多，数据库的压力越来越大。

数据库层面：

第一步应该首先考虑：读写分离（属于水平分库），解决访问压力。

• 在大部分互联网业务场景中，读操作的比例远远大于写操作，而读取数据通常耗时比较长，占用数据库服务器的CPU较多，从而影响用户体验。这时，数据库的读压力会首先成为数据库的瓶颈，而此时SQL的查询优化已很难达到要求了。在数据库层面，我们首先采用的是数据库读写分离技术，消除读写锁冲突，来提升业务系统的读性能。

第二步：垂直分库（按业务来分），解决库中表太多，数据量太大

• 数据量急剧快速增长，数据库会成为整个系统的瓶颈。这时可以考虑按照业务把不同的数据放到不同的库中。垂直切分后业务清晰，不同业务放在不同的库中，将原来所有压力由同一个库分散到不同的库中，提升了系统的吞吐量。

第三步：分表（水平方向），解决单表数据量太大

• 水平分表主要用于业务架构无法继续细分、数据库中单张表数据量太大、查询性能下降的场景。
• 一般用的是水平分表：根据id来，每个表的结构一样，只是存的数据不一样，保证每个表不要存太多的数据，如再将水平分表后的这些业务子表分散到n个业务子库中，这也就是水平分库了。
• 也可以按照具体情况考虑垂直分表，即单表中的字段实在是太多了，可以把核心字段和非核心字段分开存放，表的数据结构是不一样的

一个大致的分库分表方案如上。

---

但是应该使用哪一种方式来实施数据库分库分表，还需要从数据库的瓶颈所在和项目的业务角度进行综合考虑。

• 如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、耦合度较低，那么容易实施的垂直切分必是首选。
• 如果数据库中的表并不多，但单表的数据量很大且数据热度很高，这种情况之下就应该选择水平切分， 水平切分比垂直切分要稍微复杂，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估外，还要考虑数据要如何均匀分散。

在现实项目中，往往是这两种情况兼而有之，综合使用了垂直与水平切分，我们首先对数据库进行垂直切分（做垂直分库），然后针对一部分表（通常是用户数据表）进行水平切分（水平分表）。