分库分表技术的历史演变及其现代应用是怎样的？

本文共计1402个文字，预计阅读时间需要6分钟。

亲爱的，我是【架构摆渡人】，一个十年的程序员。这是分库分表系列的第一个文章，本系列将和大家分享很多在实际工作中实用的经验。如有收获，请分享给更多朋友。

大家好，我是，一只十年的程序猿。这是分库分表系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

其实这个系列有录过视频给大家学习，但很多读者反馈说看视频太慢了。也不好沉淀为文档资料，希望能有一系列文字版本的讲解，要用的时候可以快速浏览关键的知识点。那么它就来了，我再花点时间写成几篇连续的文章供大家学习。

什么是分库分表？

一般，一个应用刚开始开发的时候，都是连接一个数据库。因为这个时候业务并不复杂，处于起步阶段。当然重构类的除外，重构类的是已经很明确的需求，业务也比较成熟。

分库分表从字面去理解，就是将库进行拆分，将表进行拆分。至于拆分的方式可以有多种，拆分的粒度也可以自行控制。

起步阶段，一个数据库，如下图所示：

分库后的效果，如下图所示：

将一个库进行拆分，必然有一定的理由和动机，那么为什么要分库分表呢？

为什么要分库分表？ 性能问题

当数据库中的数据越来越多，请求量越来越高，性能会成为瓶颈。如果有个别SQL写的不好，没有走索引，则会出现全表扫描的情况，占用数据库的资源，影响其他请求。

存储空间不够

数据库部署在一台服务器上面，磁盘的空间是有限的，随着数据量的增多，磁盘的可用空间将会越来越少。如果不进行拆分，那么数据往哪写？

可用性更高

如果你只有一个库，当这个库出现问题的时候，所有的业务也就处于不能提供服务的状态。如果拆了10个库，10个库在不同的服务器上，即使某一个库出现问题，也不会影响所有的业务。