分库分表专题-CSDN博客

硬件层面
- 提升服务器硬件能力来提高数据处理能力，比如增加存储容量、CPU等；
- 提升硬件配置相对成本较高，且如果瓶颈在MySQL本身那么提高硬件带来的性能提升也是有限的；
软件层面
- 把大量数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题；
- 把大表拆分成若干小表，解决单张大表查询性能问题；

对于关系型数据库来说，磁盘I/O会成为其瓶颈，通过缓存热点数据，在一定程度来可提升系统性能；

二：分库分表方式

分库分表包括分库和分表两个部分，在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表四种方式；

2.1垂直分表

2.1.1垂直分表定义

垂直分表就是在同一数据库内将一张表按照指定字段分成若干表，每张表仅存储其中一部分字段；
垂直分表拆解了原有的表结构，拆分的表之间一般是一对一的关系；

2.1.2垂直分表优势

充分提高了热点数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累（冷热数据分离）；
避免了IO过度争抢并减少锁表的几率，查看商品详情的用户与商品信息浏览互不影响；

2.1.3垂直分表原则

把不常用的字段单独放在一张表;（因为数据库加载数据时，会将表整整行的信息加载）
把text（大文本存储），blob（图片、视频类存储）等大字段拆分出来放在附表中（阿里开发手册严禁使用text等大字段）;
经常组合查询的列放在一张表中，避免多表联查，性能最高;

2.2垂直分库

2.2.1垂直分库定义

垂直分库是指按照业务将表进行归类，然后把不同类的表分布到不同的数据库上面，而每个库又可以放在不同的服务器上，它的核心理念是-专库专用；

2.2.2垂直分库优势

通过不同表的业务聚合（聚合为库），使得数据库维护更加清晰；
能对不同业务的数据进行分级管理、维护、监控、扩展等；
高并发场景下，垂直分库在一定程度上提高了磁盘IO和数据库连接数，并改善了单机硬件资源的瓶颈问题；

2.3水平分表

2.3.1水平分表定义

水平分表就是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，表的结构没有变化；
水平分表解决单表数据量大的问题

2.3.2水平分表优势

水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，它带来的提升是：

优化单一表数据量过大而产生的性能问题;
避免IO争抢并减少锁表的几率;

整体看，水平分表仅仅解决了单表数据量过大的问题，但是没有解决单库数据量过大的问题；

2.4水平分库

2.4.1水平分库定义

水平分库可以看做是水平分表的进一步拆分，是把同一个表的数据按一定规则拆到不同的数据库中，每个库又可以部署到不同的服务器上；
水平分库解决了单库数据量大的问题，突破了服务器物理存储的瓶颈；

2.4.2水平分库优势

水平分库带来的提升是：

解决了单库大数据，高并发的性能瓶颈问题；
提高了系统的稳定性及可用性；

总之，当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平分库了，经过水平切分的优化，往往能==解决单库存储量及性能瓶颈==。但由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大提升了系统复杂度。

虽然分库分表能有效的缓解了单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。

分布式事务一致性问题

跨节点关联查询

跨节点分页、排序函数

主键避重

公共表(小数据量的表且经常使用，可能存在联查的情况）

显然如果我们自己去解决上述问题，开发工作量较大，所以我们就有必要学习一种支持分库分表特性的技术：sharding-jdbc、mycat等；

三：sharding-JDBC入门

3.1ShardingSphere

Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，核心由： JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成；

功能特性：它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

官方网站：Apache ShardingSphere

文档地址：概览 :: ShardingSphere

本教程主要介绍：Sharding-JDBC；

Sharding-jdbc是ShardingSphere的其中一个模块，定位为==轻量级Java框架==，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

Sharding-JDBC的核心功能为数据分片和读写分离，通过Sharding-JDBC，应用可以透明的使用jdbc访问已经分库分表、读写分离的多个数据源，而不用关心数据源的数量以及数据如何分布。

3.2sharding-jdbc相关名词解释

参考官网-核心概念

逻辑表（LogicTable）：进行水平拆分的时候同一类型（逻辑、数据结构相同）的表的总称。例：用户数据根据主键尾数拆分为2张表，分别是tab_user_0到tab_user_1，他们的逻辑表名为tab_user。
真实表（ActualTable）：在分片的数据库中真实存在的物理表。即上个示例中的tab_user_0到tab_user_1。
数据节点（DataNode）：数据分片的最小单元。由数据源名称和数据表组成，例：spring-boot_0.tab_user_0，spring-boot_0.tab_user_1，spring-boot_1.tab_user_0，spring-boot_1.tab_user_1。

说白了，具体到指定库下的指定表就是一个数据节点；
动态表（DynamicTable）：逻辑表和物理表不一定需要在配置规则中静态配置。如，按照日期分片的场景，物理表的名称随着时间的推移会产生变化（股票流水）。
广播表（公共表）：指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。
分片键（ShardingColumn）：分片字段用于将数据库（表）水平拆分的字段，支持单字段及多字段分片。例如上例中的order_id。一般在业务中经常查询使用的字段会作为分片键；

3.3 sharding-jdbc的执行原理

参考官网-内部剖析：

3.4sharding-jdbc分片方式

3.4.1inline模式

使用最简单，开发成本比较低；
只能使用单个字段作为分片键；
基于行表达式定义分片规则；

通过groovy表达式来表示分库分表的策略；
db0
├── t_order0
└── t_order1
db1
├── t_order0
└── t_order1
表达式：db${0..1}.t_order${0..1}
t_order${orderId % 2}

3.4.2standard标准分片模式

用户可通过代码自定义复杂的分片策略；
同样只能使用单个字段作为分片键；

3.4.3complex复合分片模式

用于多分片键的复合分片策略（多片键）

3.4..4Hint强制分片模式

不指定片键，通过代码动态指定路由规则
强制分片策略（强制路由）

四：总结

分库分表方式：垂直分表、垂直分库、水平分库和水平分表

垂直分表：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失【同一库中将单张表按照字段拆分成若干表，拆分后表的记录行数不变】。

垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。【根据业务将表分组形成不同的库，这些库又可以部署到不同的数据库中-专库专用】

水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。【同一数据库中将大表拆分成若干小表，每张表的结构一致，但保存的数据不同】

水平分库：可以把表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。

最佳实践：

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案。当然在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。

总之，基于开发和维护成本比考虑，非必须，不要对数据库做分库分表处理！