分库分表会带来读扩散问题？怎么解决？

分库分表

我们平时做项目开发。一开始，通常都先用一张数据表，而一般来说数据表写到2kw条数据之后，底层B+树的层级结构就可能会变高，不同层级的数据页一般都放在磁盘里不同的地方，换言之，磁盘IO就会增多，带来的便是查询性能变差。 如果对上面这句话有疑惑的话，可以去看下我之前写的文章。

于是，当我们单表需要管理的数据变得越来越多，就不得不考虑数据库 分表 。而这里的分表，分为 水平分表和垂直分表 。

垂直分表的原理比较简单，一般就是把某几列拆成一个新表，这样单行数据就会变小，B+树里的单个数据页（固定16kb）内能放入的行数就会变多，从而使单表能放入更多的数据。

垂直分表没有太多可以说的点。下面，我们重点说说最常见的 水平分表 。

水平分表有好几种做法，但不管是哪种，本质上都是将原来的 user 表，变成 user_0, user1, user2 .... uerN 这样的N多张小表。

从读写一张user 大表 ，变成读写 user_1 … userN 这样的N张 小表 。

分表

每一张小表里，只保存一部分数据，但具体保存多少，这个自己定，一般就订个 500w~2kw 。

那分表具体怎么做？

根据id范围分表

我认为最好用的，是根据id范围进行分表。

我们假设每张分表能放 2kw 行数据。那user0就放主键id为 1~2kw 的数据。user1就放id为 2kw+1 ~ 4kw ，user2就放id为 4kw+1 ~ 6kw ， userN就放 2N kw+1 ~ 2(N+1)kw 。

根据id范围分表

假设现在有条数据，id=3kw，将这个 3kw除2kw = 1.5 ，向下取整得到 1 ，那就可以得到这条数据属于 user1表 。于是去读写user1表就行了。这就完成了数据的路由逻辑，我们把这部分逻辑封装起来，放在数据库和业务代码之间。

这样。 对于业务代码来说 ，它只知道自己在读写一张 user 表，根本不知道底下还分了那么多张小表。

对于数据库来说，它并不知道自己被分表了，它只知道有那么几张表，正好名字长得比较像而已。

这还只是在 一个数据库 里做分表，如果范围再搞大点，还能在&