前言
关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。 当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。 此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分(Sharding)，以及切分后对数据的定位、整合。 数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式： 垂直(纵向)切分和水平(横向)切分
垂直(纵向)切分
垂直切分常见有垂直分库和垂直分表两种。
垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。
简而言之就是 把单一数据库按照业务需求进行划分，分为专库专表的形式！
垂直分表
基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下(例如一个大表有100多个字段)，通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。
例如当前有一个商品表：
| 商品名称 | varchar |
| 商品封面 | varchar |
| 商品价格 | int |
| 商品描述 | varchar |
| 商品其他描述 | varchar |
商品基础信息表：
| 商品名称 | varchar |
| 商品封面 | varchar |
| 商品价格 | int |
商品描述信息表：
| 商品描述 | varchar |
| 商品其他描述 | varchar |
操作数据库中有某张表，将该表的一部分字段拿出分为一张表，其他字段分为一张表。（按需分配）将其按照字段分为多 个表，数据条数是一致的。
此时，垂直分表后表仍在一个数据库中，由于表的数量增加了，所以增加了当前数据库的IO，这时我们就需要垂直分库操作了！
垂直切分的优点：
解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点：
部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
依然存在单表数据量过大的问题(需要水平切分)
水平(横向)切分
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。
水平分库
将商品数据库划分为商品数据库A和商品数据库B，判断商品ID为奇数的存入A库，为偶数的存入B库。这样就使假设原本单库10w条数据的数据库分为了两个数据量5w条的数据库，减少了单库的数据量，提高CURD操作效率。
水平分表
以上经过垂直分库分表，水平分库后，仍会造成单表数据量过大的问题，难道再进行水平分库为A.B.C.D.E.F…？如果再 进行水平分库，又将增加服务器，不仅提高了硬件成本，运维起来也很不方便。
这时，可采用水平分表操作，在垂直分库分表以及水平分库的基础上，将每个服务器上的商品数据库A，B中商品基础信息表和商品描述表水平切分，例如可根据商品ID奇偶来分为商品基础信息表1，2...商品描述信息表1，2...
这样，就可在不增加服务器的条件下将巨大数据量的单表分为多个数据量一般的表，提高CURD效率。