分库分表系列：分库分表的前世今生

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

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

什么是分库分表？

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

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

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

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

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

为什么要分库分表？

性能问题

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

存储空间不够

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

可用性更高

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

业务划分

当所有的业务表都在一个库中，本身就会存在资源抢占和相互影响的情况。同时也不利于多团队的开发，大家的表都在一起，万一误操作了怎么办。这么多表，哪些是我的，哪些是你的？

分库分表的方式有哪些？

什么是垂直拆分？

垂直拆分就是把一个数据库拆分成多个数据库的操作。假设你的数据库中有用户表，商品表，订单表等。这些是属于不同的业务场景，就算不从性能的角度考虑，也要进行拆分，这个就是根据业务进行划分，这就是垂直拆分的一种。

进行垂直拆分之后结构更清晰了，数据库的整体性能也上来了。以前一个库要顶住1W的QPS,现在平摊到三个数据库上面了，每个数据库只需要顶住3K多就够了，前提是你这3个数据库必须是独立的实例。

垂直拆分，也同时了解决了存储的问题，整体的存储空间其实也拆分开了。

什么是水平拆分

水平拆分跟垂直拆分可以进行互补，垂直拆分主要是容量和业务划分的拆分。水平拆分主要就是为了解决容量和性能问题的拆分。

比如你拆了订单库，商品库，用户库。但是订单库还是在一个数据库上面，他的性能和存储还是有瓶颈的。此时就要进行水平拆分了，水平拆分就是把一个订单库，拆分成多个库，一个订单表拆分成多个表。

订单库从一个库一个表拆分成多个库多个表，如下图所示：

总结

今天主要跟大家讲了下背景，以及为什么要做分库分表。让大家有个整体的概念，这样后面学习起来就会比较容易了。

虽然我们知道要做分库分表，但是在分的时候该怎么分呢？垂直和水平如何搭配，才能干活不累呢？请关注我，下篇文章为你揭秘。

原创：架构摆渡人（公众号ID：jiagoubaiduren），欢迎分享，转载请保留出处。

本文已收录至学习网站 http://cxytiandi.com/ ，里面有Spring Boot, Spring Cloud，分库分表，微服务，面试等相关内容。