为什么要分库分表？

1. 什么时候才需要分库分表呢？我们的评判标准是什么？
2. 一张表存储了多少数据的时候，才需要考虑分库分表？
3. 数据增长速度很快，每天产生多少数据，才需要考虑做分库分表？

答案很简单：数据库出现性能瓶颈。用大白话来说就是数据库快扛不住了。

举一个例子，如全国气象站数据采集系统，每1分钟一个测量度，每分钟采集7、8（风速、温度、湿度…）个维度，这样的设备全国有30多万套，简单计算下每天 30W * 7 * （1440 + N） 的数据量（N代表其他关联属性），这样的数据模型怎么建？？

这样的数据，如果放在一张表里，不出半年，首先查询和更新效率会变的极低，请求分析频率高的话，那简直是灾难。再过上段时间，我也不知道为怎么样，最直接的表都可能打不开，还不谈存储够不够。

这时候，分表的需求就出现了，最简单莫过于 一天一张表！！！

然后我们把时间维度再拉长一点，随着时间推移，系统运行了5年，10年，这时候新问题就来了，你们能想像一下吗，最直接的场景就是，数据库能进，但是库下面的表由于太多，表索引变慢，刷新一下可能要个3、4分钟，这种情况于后台程序做查询、更新、数据请求、存储等都将变成问题。

分库分表的需求，是随着时间推移，慢慢产生的，当大量请求阻塞、SQL 操作变慢、存储出现问题，系统将不得不面临这些问题。

从机器的角度看，性能瓶颈无非就是 CPU、内存、磁盘、网络这些，要解决性能瓶颈最简单粗暴的办法就是提升机器性能，但是通过这种方法，能短暂的解决问题，不管是CPU、内存、磁盘，这些性能提升是有天花板的，不能像数据增涨那样无限制的持续下去，这时候我们就需要从软件层面解决问题。

软件层面解决思路：SQL 调优、表结构优化、读写分离、数据库集群、分库分表、加索引等。

当单台数据库实例扛不住，我们可以增加实例组成集群对外服务。

当发现读请求明显多于写请求时，我们可以让主实例负责写，从实例对外提供读的能力；如果读实例压力依然很大，可以在数据库前面加入缓存如 redis，让请求优先从缓存取数据减少数据库访问。

缓存分担了部分压力后，数据库依然是瓶颈，这个时候就可以考虑分库分表的方案了。

那么，分库分表后，需要注意什么？
跨库关联查询

在单库未拆分表之前，我们可以很方便使用 join 操作关联多张表查询数据，但是经过分库分表后两张表可能都不在一个数据库中，如何使用 join 呢？有几种方案可以解决：

• 字段冗余：把需要关联的字段放入主表中，避免 join 操作；
• 数据抽象：通过ETL等将数据汇合聚集，生成新的表；
• 全局表：比如一些基础表可以在每个数据库中都放一份；
• 应用层组装：将基础数据查出来，通过应用程序计算组装。

排序、分页、函数计算问题
在使用 SQL 时 order by、limit 等关键字需要特殊处理，一般来说采用分片的思路：先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终得到结果。

分布式 ID
单库单表使用 id 自增作为主键，分库分表了之后就不行了，会出现 ID重复。常用的分布式 ID 解决方案有：

• UUID
• 号段模式
• Redis 缓存
• 雪花算法（Snowflake）

如果出现数据库问题不要着急分库分表，先看一下使用常规手段是否能够解决。

分库分表会给系统带来巨大的复杂性，不是万不得已建议不要提前使用。作为系统架构师可以让系统灵活性和可扩展性强，但是不要过度设计和超前设计。在这一点上，架构师一定要有前瞻性，提前做好预判。