关系数据库本身容易成为系统瓶颈，独立存储器的容量、连接数和处理能力有限。 在单表数据量达到1000W或100G后，由于查询维数较大，即使从库中添加索引或优化索引，大量操作也会导致性能严重下降。 这个时候，有必要考虑分割这个。 分割的目的是减少数据库的负担，缩短查询时间。
1、垂直分区表垂直分区表在日常开发和设计中很常见。 一般被称为“dddsmt分解表”，并且分割是基于关系数据库的“列”(字段)来执行的。 由于表中的字段通常很多，因此可以创建一个新的“扩展表”，将不常用或长字段拆分为“扩展表”，如下图所示。
字段较多时，分割更容易开发和维护。 从某种意义上说，也可以避免“跨页”问题。 (MySQL、MSSQL的基础全部保存在“数据页”中。 “扩散”问题可能会造成额外的性能开销，因此不在此处展开。 感兴趣的人可以自己调查研究相关资料。 一个表字段的数量最好不要超过40个。
但垂直分割表最好在系统设计阶段设计，后期维护分割分量较大。
2、垂直分库在“微服务”盛行的今天非常普及。 的基本思想是根据不同的业务模块划分不同的数据库，而不是像最初那样将所有数据表放在同一个数据库中。 下图：
总结系统级“服务化”细分操作，可以解决业务系统级的耦合和性能瓶颈，有利于系统的扩展维护。 数据库级别的分割也是说得通的。 与服务的“治理”和“降级”机制类似，您还可以对不同业务类型的数据进行“分类”管理、维护、监控和扩展。
众所周知，数据库容易成为APP应用系统的瓶颈，但数据库本身是“有状态的”，很难对Web和APP应用服务器实现“横向扩展”。 的连接资源相对宝贵，单体的处理能力也有限，在高并发的场景下，垂直库可以在一定程度上突破IO、连接数和单体硬件资源的瓶颈，优化大型分布式系统中的数据库架构如果拆分后出现许多问题(例如，跨库join、分布式事务等)，也需要考虑。
3、水平分割表水平分割表也叫横向分割表，很容易理解。 通过将表中不同的数据行按照一定的规则分布在不同的数据库表中，减少单个表的数据量，优化查询性能。 最常见的方法是在主键和时间等字段中取Hash和模型，然后进行分割。 如下图所示。
**水平分割表： **表很大，通过分割可以减少查询时阅读的数据和索引的页数。 此外，还可以减少索引的层级数，增加查询次数
通过摘要级划分表，可以减少单表的数据量，在一定程度上缓解查询性能的瓶颈。 但是，本质上这些表仍然存储在同一数据库中，因此在库级别仍然存在IO瓶颈。 所以，一般不推荐这样的做法。
4、水平分库水平分库与上述水平分表的思想相同，唯一的区别是将这些分割的表保存在不同的数据中。 这也是许多大型互联网公司选择的做法。 下图：
从某种意义上说，某些系统使用的“冷热数据分离”(将非活动历史数据迁移到其他数据库)。 业务功能通常在缺省情况下仅提供热点数据查询)也是类似的实践。 在高并发性和大数据量的场景下，库分区表可以有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数和硬件资源瓶颈。 当然，投入的硬件成本也很高。 它还会产生复杂的技术问题和挑战，例如分片之间的复杂查询，分片之间的事务
参考：
3359 www.infoq.cn/article/key-steps-and-likely-problems-of-split-table /
3359 www.cn blogs.com/butterfly 100/p/9034281.html