01-分库分表-总体概述

分库分表-总体概述

为什么要分库分表

数据库性能瓶颈的出现

对于应用来说，如果数据库性能出现问题，要么是无法获取连接，是因为在高并发的情况下连接数不够了。要么是操作数据变慢，数据库处理数据的效率出了问题。要么是存储出现问题，比如单机存储的数据量太大了，存储的问题也可能会导致性能的问题。

归根结底都是受到了硬件的限制，比如 CPU，内存，磁盘，网络等等。但是我们优化肯定不可能直接从扩展硬件入手，因为带来的收益和成本投入比例太比。

所以我们先来分析一下，当我们处理数据出现无法连接，或者变慢的问题的时候，我们可以从哪些层面入手。

数据库优化方案对比

数据库优化有很多层面。

SQL 与索引

因为SQL语句是在我们的应用端编写的，所以第一步，我们可以在程序中对SQL语句进行优化，最终的目标是用到索引。这个是容易的也是最常用的优化手段。

表与存储引擎

第二步，数据是存放在表里面的，表又是以不同的格式存放在存储引擎中的，所以我们可以选用特定的存储引擎，或者对表进行分区，对表结构进行拆分或者冗余处理， 或者对表结构比如字段的定义进行优化。

架构

第三步，对于数据库的服务，我们可以对它的架构进行优化。

如果只有一台数据库的服务器，我们可以运行多个实例，做集群的方案，做负载均衡。

或者基于主从复制实现读写分离，让写的服务都访问master服务器，读的请求都访问从服务器，slave服务器自动master主服务器同步数据。

或者在数据库前面加一层缓存，达到减少数据库的压力，提升访问速度的目的。

为了分散数据库服务的存储压力和访问压力，我们也可以把不同的数据分布到不同的服务节点，这个就是分库分表(scale out)。

注意主从(replicate)和分片(shard)的区别:

• 主从通过数据冗余实现高可用，和实现读写分离。
• 分片通过拆分数据分散存储和访问压力。

配置

第四步，是数据库配置的优化，比如连接数，缓冲区大小等等，优化配置的目的都是为了更高效地利用硬件。

操作系统与硬件

最后一步操作系统和硬件的优化。

从上往下，成本收益比慢慢地在增加。所以肯定不是查询一慢就堆硬件，堆硬件叫做向上的扩展(scale up)。

什么时候才需要分库分表呢?我们的评判标准是什么?

如果是数据量的话，一张表存储了多少数据的时候，才需要考虑分库分表?

如果是数据增长速度的话，每天产生多少数据，才需要考虑做分库分表?

如果是应用的访问情况的话，查询超过了多少时间，有多少请求无法获取连接，才需要分库分表?这是一个值得思考的问题。