一文读懂数据库分库分表

分库分表，是企业里面毕竟常见的针对高并发、数据量大的场景下的一种技术优化方案，也是一个非常高频的面试题。但是，因为很多人其实并没有非常丰富的分库分表的经验，所以能把这个问题回答的比较好的人其实还挺少的。

那么，本文就来试图把关于分库分表的事情，一次性的讲个清楚。

分库，分表，分库分表

首先，我们需要知道所谓"分库分表"，根本就不是一件事儿，而是三件事儿，他们要解决的问题也都不一样。

这三个事儿分别是"只分库不分表"、“只分表不分库”、以及"既分库又分表"。

什么时候分库？

其实，分库主要解决的是并发量大的问题。因为并发量一旦上来了，那么数据库就可能会成为瓶颈，因为数据库的连接数是有限的，虽然可以调整，但是也不是无限调整的。

所以，当当你的数据库的读或者写的QPS过高，导致你的数据库连接数不足了的时候，就需要考虑分库了，通过增加数据库实例的方式来提供更多的可用数据库链接，从而提升系统的并发度。

比较典型的分库的场景就是我们在做微服务拆分的时候，就会按照业务边界，把各个业务的数据从一个单一的数据库中拆分开，分表把订单、物流、商品、会员等单独放到单独的数据库中。

还有就是有的时候可能会需要把历史订单挪到历史库里面去。这也是分库的一种具体做法。

什么时候分表？

分库主要解决的是并发量大的问题，那分表其实主要解决的是数据量大的问题。

假如你的单表数据量非常大，因为并发不高，数据量连接可能还够，但是存储和查询的性能遇到了瓶颈了，你做了很多优化之后还是无法提升效率的时候，就需要考虑做分表了。

通过将数据拆分到多张表中，来减少单表的数据量，从而提升查询速度。

一般我们认为，单表行数超过 500 万行或者单表容量超过 2