垂直分表方案
- 表的记录并不多，但是字段却很长，表占用空间很大，检索表的时候需要执行大量的IO，严重降低了性能。这时需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。
为什么垂直拆分之后查询性能就变快了？
- 由于数据量本身大，需要更长的读取时间。
- 跨页，页是数据库存储单位，很多查找及定位操作都是以页为单位，单页内的数据行越多数据库整体性能越好，而大字段占用空间大，单页内存储行数少，因此IO效率较低。
- 数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。
水平分表方案
ID取模分表
优点
- 分表比较简单，并且数据都可以很均匀的分摊到每个分表上。
缺点
- 如果想要扩展表的个数，比如从2张表变成3张表。那同样还是id=3的数据，以前3和2取模得到1，所以ID=3的数据会放在user1表里，现在3和3取模得到0，那就要存在在user0这张表里，跟原来的user1对不上了，这就需要考数据迁移的问题了。当然也可以在一开始就对数据进行预估建立多张表。
ID范围分表
优点
- 设置每张表的存放的数据范围，这样就可以很好的解决ID取模时数据扩展的问题。数据少的时候，表也少，随着数据增多，表会慢慢变多。而且这样表还可以无限扩展。
缺点
- 根据id范围去做分表，因为id是递增的，那新写入的数据一般都会落到某一张表上，如果你的业务场景写数据特别频繁，那这张表就会出现写热点的问题。
ID取模分表+ID范围分表
- 可以在ID范围分表后再增加几张表进行ID取模分表。比如通过ID范围分表后得到user1表，此时可以增加user1-1、user1-2、user1-3等三张表来进行ID取模，以此减少单表的读写压力。
什么是读扩散问题？
- 理想情况下我们已知一个id，不管是根据哪种规则，我们都能很快定位到该读哪个分表。但很多情况下，我们的查询又不是只查主键，如果我的数据库表有一列name，并且加了个普通索引。由于name并不是分片键，我们我们没法定位到具体要到哪个分表上去执行sql，于是就会对所有分表进行查询，随着我的表越来越多，次数会越来越多，这就是所谓的读扩散问题。
如何解决读扩散问题？
- 我们可以单独建个新的分片表，这个新表里的列就只有旧表的主键id和普通索引列，而这次换普通索引列来做分片键。
- 当我们要查询普通索引列时，先到这个新的分片表里做一次查询，就能迅速定位到对应的主键ID，然后再拿主键ID去旧的分片表里再查一次数据，这个做法的缺点就是需要维护两套表，并且普通索引列更新时，要两张表同时进行更改。也可以使用es+mysql来实现。
