第二章 分库分表方式
分库分表包括分库和分表两个部分，在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表四种方式；
1、垂直分表
1.1 垂直分表定义
-
垂直分表就是在同一数据库内将一张表按照指定字段分成若干表，每张表仅存储其中一部分字段；
-
垂直分表拆解了原有的表结构，拆分的表之间一般是一对一的关系；
1.2 垂直分表场景示例
1.2.1 场景说明
下边通过一个商品查询的案例讲解垂直分表，通常在商品列表中是不显示商品详情信息的，如下图：
说明：
-
用户浏览商品列表时只对感兴趣商品查看商品详情：商品描述信息被访问的频次较低，且该字段占用存储空间较大；
-
商品表字段出现部分字段访问频次不一致的情况：商品名称、商品图片、商品价格等其他字段数据访问频次较高
由于这两组数据的特性不一样，因此我们可以考虑将商品信息表拆分如下，将访问频次低的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中：
商品列表可采用以下sql：
SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]
FROM [商品信息] p
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码]
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]
WHERE...ORDER BY...LIMIT...需要获取商品描述时，再通过以下sql获取：
SELECT *
FROM [商品描述]
WHERE [商品ID] = ?1.2.2 垂直分表优势
-
充分提高了热点数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累（冷热数据分离）；
-
避免了IO过度争抢并减少锁表的几率，查看商品详情的用户与商品信息浏览互不影响；
1.2.3 垂直分表原则
-
把不常用的字段单独放在一张表;（因为数据库加载数据时，会将表整整行的信息加载）
-
把text（大文本存储），blob（图片、视频类存储）等大字段拆分出来放在附表中（阿里开发手册严禁使用text等大字段）;
-
经常组合查询的列放在一张表中，避免多表联查，性能最高;
2、垂直分库
2.1 垂直分表存在的问题
-
经过垂直分表后表的查询性能确实得到了一定程度的提升，但数据始终限制在同一台机器内，因此因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘；
-
单台服务器的性能瓶颈（比如：CPU、内存、网络IO、磁盘等）通过垂直分表始终得不到突破；
2.2 垂直分库定义
垂直分库是指按照业务将表进行归类，然后把不同类的表分布到不同的数据库上面，而每个库又可以放在不同的服务器上，它的核心理念是-专库专用；
2.3 示例场景
经过思考，我们可以将原有的卖家库，拆分为分为商品库和店铺库，并把这两个库分散到不同服务器上，如下图：
注意事项：
由于商品信息与商品描述业务耦合度较高，因此一起被存放在商品库（避免跨库联查）； 店铺信息相对独立，因此可单独被存放在店铺库下； 对于地理区域表，因为商品信息和店铺信息都需要，且地理区域是不经常变动的常量表但是会存在与其他表联查的情况，所以可以将它作为公共表分别等量部署到不同的数据库节点下； 以上操作就可以称为垂直分库。
2.4垂直分库优势
垂直分库带来的提升是：
-
通过不同表的业务聚合（聚合为库），使得数据库维护更加清晰；
-
能对不同业务的数据进行分级管理、维护、监控、扩展等；
-
高并发场景下，垂直分库在一定程度上提高了磁盘IO和数据库连接数，并改善了单机硬件资源的瓶颈问题；
但是，垂直分库依然没有解决库中单表数据量过大的问题！
3、 水平分表
3.1水平分表定义
-
水平分表就是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，表的结构没有变化；
-
水平分表解决单表数据量大的问题；
3.2 水平分表示例
为解决单表数据量大的问题，我们可把商品库内的表进行水平拆分，得到若干相同表结构的小表；
需要注意的是各个小表存储的数据不同，且数据依旧保存在同一个数据库内；
如下图：
分表算法说明：
如果商品ID为双数，将此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1];
这种操作就叫做：水平分表。
3.3 水平分表优势
水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，它带来的提升是：
-
优化单一表数据量过大而产生的性能问题;
-
避免IO争抢并减少锁表的几率;
整体看，水平分表仅仅解决了单表数据量过大的问题，但是没有解决单库数据量过大的问题；
4、水平分库
4.1 水平分库定义
-
水平分库可以看做是水平分表的进一步拆分，是把同一个表的数据按一定规则拆到不同的数据库中，每个库又可以部署到不同的服务器上；
-
水平分库解决了单库数据量大的问题，突破了服务器物理存储的瓶颈；
4.2 水平分库示例场景
经过垂直分库和水平分表后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，商品库单库存储数据已经超出预估。
假如当前有8w店铺，每个店铺平均150个不同规格的商品，那商品数量得往1200w+上预估，并且商品库属于访问非常频繁的资源，单台服务器已经无法支撑。
此时该如何优化？
目前情况是那怕再次垂直分库也无法解决数据瓶颈问题。我们可以尝试水平分库，将商品ID为单数的和商品ID为双数的商品信息分别放在两个不同库中；
说明：
如果商品ID为双数，将此操作映射至【商品库-1】； 如果店铺ID为单数，将操作映射至【商品库-2】； 此操作要访问数据库名称的表达式为：商品库_(商品ID%2 + 1)； 这种操作就叫水平分库。 总之，水平分库后，各个库保存的表结构是一致的，但是表中内容不一样；
4.3 水平分库优势
水平分库带来的提升是：
-
解决了单库大数据，高并发的性能瓶颈问题；
-
提高了系统的稳定性及可用性；
总之，当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平分库了，经过水平切分的优化，往往能==解决单库存储量及性能瓶颈==。但由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大提升了系统复杂度。
5、分库分表带来的问题
分库分表能有效的缓解了单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。
-
分布式事务一致性问题
-
跨节点关联查询
-
跨节点分页、排序函数
-
主键避重
-
公共表(小数据量的表且经常使用，可能存在联查的情况）
显然如果我们自己去解决上述问题，开发工作量较大，所以我们就有必要学习一种支持分库分表特性的技术：sharding-jdbc、mycat等；
6、分库分表小结
分库分表方式：垂直分表、垂直分库、水平分库和水平分表
垂直分表：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失【同一库中将单张表按照字段拆分成若干表，拆分后表的记录行数不变】。
垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。 【根据业务将表分组形成不同的库，这些库又可以部署到不同的数据库中-专库专用】
水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。【同一数据库中将大表拆分成若干小表，每张表的结构一致，但保存的数据不同】
水平分库：可以把表的数据(按数据行)分 到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。
最佳实践：
一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案。当然在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。
总之，基于开发和维护成本比考虑，非必须，不要对数据库做分库分表处理！