🚀 10分钟掌握MySQL分库分表

黑马研究院
565 阅读21分钟

导读：

哈喽，小伙伴们，我是黑马苗老师。

随着订单数据的增加，当MySQL单表存储数据达到一定量时其存储及查询性能会下降，在阿里的《Java 开发手册》中提到MySQL单表行数超过 500 万行或者单表容量超过 2GB时建议进行分库分表。

如何对MySQL数据库进行分库分表？

本文用10分钟时间带你掌握MySQL分库分表的最佳技术方案。

什么是分库分表

下边通过一个例子来说明什么是分库分表。

下边是一个电商系统的数据库，涉及了店铺、商品的相关业务。

1564473125313-1727960203900.png

随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，如何优化呢？

我们可以把数据分散在不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的，如下图：将电商数据库拆分为若干独立的数据库，并且对于大表也拆分为若干小表，通过这种数据库 拆分的方法来解决数据库的性能问题

1566806361503.png

​

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成 ，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目 的。

分库分表的四种方式

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

垂直分表

下图是商品查询列表：

1564543779745-1727960475741.png

用户在浏览商品列表时，只有对某商品感兴趣时才会查看该商品的详细描述。因此，商品信息中商品描述字段访问 频次较低，且该字段存储占用空间较大，访问单个数据IO时间较长；商品信息中商品名称、商品图片、商品价格等 其他字段数据访问频次较高。

由于这两种数据的特性不一样，因此考虑将商品信息表拆分如下：

将访问频次低的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中。

1564473677392-1727960677958.png

垂直分表是将一个表按照字段分成多表，每个表存储其中一部分字段，比如按冷热字段进行拆分。

垂直分表带来的好处是：充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累。

通常我们按以下原则进行垂直拆分:

  1. 把不常用的字段单独放在一张表;
  2. 把text，blob等大字段拆分出来放在附表中;
  3. 经常组合查询的列放在一张表中;

垂直分库

通过垂直分表性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终限

制在一台服务器，库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同的服务器上，因此每个

表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。

经过思考，他把原有的SELLER_DB(卖家库)，分为了PRODUCT_DB(商品库)和STORE_DB(店铺库)，并把这两个库分 散到不同服务器，如下图：

1564479268747-1727960754631.png

由于商品信息与商品描述业务耦合度较高，因此一起被存放在PRODUCT_DB(商品库)；而店铺信息相对独立，因此 单独被存放在STORE_DB(店铺库)。

垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念 是专库专用，微服务架构下通常会对数据库进行垂直分为，不同业务数据放在单独的数据库中，比如：客户信息数据库、订单数据库等。

垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多

个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题。

它带来的提升是：

1、解决业务层面的耦合，业务清晰

2、能对不同业务的数据进行分级管理、维护、监控、扩展等

3、高并发场景下，垂直分库一定程度的提升IO、降低单机硬件资源的瓶颈。

水平分库

经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，PRODUCT_DB(商品库)单库存储数据已经超出预估。粗略估计，目前有8w店铺，每个店铺平均150个不同规格的商品，再算上增长，那商品数量得 往1500w+上预估，并且PRODUCT_DB(商品库)属于访问非常频繁的资源，单台服务器已经无法支撑。此时该如何 优化？

再次分库？但是从业务角度分析，目前情况已经无法再次垂直分库。

尝试水平分库，将店铺ID为单数的和店铺ID为双数的商品信息分别放在两个库中。

1564479533473-1727960811431.png

也就是说，要操作某条数据，先分析这条数据所属的店铺ID。如果店铺ID为双数，将此操作映射至 RRODUCT_DB1(商品库1)；如果店铺ID为单数，将操作映射至RRODUCT_DB2(商品库2)。

水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上，比如：单数订单在db_orders_0数据库，偶数订单在db_orders_1数据库。

当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进

行水平分库了，经过水平切分的优化，往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据

库，需要额外进行数据操作的路由工作，因此大大提升了系统复杂度。

它带来的提升是：

1、解决了单库大数据，高并发的性能瓶颈。

2、提高了系统的稳定性及可用性。

水平分表

按照水平分库的思路把PRODUCT_DB_X(商品库)内的表也可以进行水平拆分，其目的也是为解决单表数据量大 的问题，如下图：

1564480703539-1727960894149.png

与水平分库的思路类似，不过这次操作的目标是表，商品信息及商品描述被分成了两套表。如果商品ID为双数，将 此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品 信息[商品ID%2 + 1]

水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中，比如：0到500万的订单在orders_0数据、500万到1000万的订单在orders_1数据表。

水平分表优化了单一表数据量过大而产生的性能问题

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

分库分表带来的问题

事务一致性问题

由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。

跨节点关联查询

在没有分库前，我们检索商品时可以通过以下SQL对店铺信息进行关联查询：

SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] 
FROM [商品信息] p 
LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] 
LEFT JOIN [店铺信息] s ON s.id = p.[所属店铺] 
WHERE...ORDER BY...LIMIT...

但垂直分库后**[商品信息]和[店铺信息]**不在一个数据库，甚至不在一台服务器，无法进行关联查询。

可将原关联查询分为两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数

据，最后将获得到的数据进行拼装。

跨节点分页、排序函数

跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据

进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。

如，进行水平分库后的商品库，按ID倒序排序分页，取第一页:

1564649127468-1727961187589.png

以上流程是取第一页的数据，性能影响不大，但由于商品信息的分布在各数据库的数据可能是随机的，如果是取第

N页，需要将所有节点前N页数据都取出来合并，再进行整体的排序，操作效率可想而知。所以请求页数越大，系

统的性能也会越差。

在使用Max、Min、Sum、Count之类的函数进行计算的时候，与排序分页同理，也需要先在每个分片上执行相应

的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。

主键避重

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。

1564650402464-1727961229998.png

公共表

实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。例子中地理区域表也属于此类型。

可以将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行。

分库分表解决方案

由于分库分表之后，数据被分散在不同的数据库、服务器。因此，对数据的操作也就无法通过常规方式完成，并且 它还带来了一系列的问题。好在，这些问题不是所有都需要我们在应用层面上解决，市面上有很多中间件可供我们 选择。

在项目中选择分库分表方案时，通常会考虑到技术成熟度、社区支持、易用性、性能等因素。以下是一些在实际应用中较为常用的分库分表解决方案：

  1. ShardingSphere（Apache ShardingSphere）：
    • 随着ShardingSphere成为Apache的顶级项目，其稳定性和功能得到了广泛的认可。它支持多种分片算法，可以作为JDBC客户端直接集成到应用程序中，也可以作为数据库代理部署，提供透明化的分库分表能力。
    • ShardingSphere的优势在于它的灵活性和扩展性，支持水平分片、垂直分片等多种模式，并且集成了读写分离、数据加密等功能。
  2. MyCat：
    • MyCat是一个轻量级的数据库中间件，适用于那些希望快速实现分库分表的企业。尽管它的功能相比ShardingSphere来说可能略显简单，但它依然提供了足够的灵活性来满足大多数应用场景的需求。
    • MyCat适合于已经有稳定架构的企业，希望在不改变太多现有代码的基础上引入分库分表机制。
  3. 手工编码实现：
    • 在一些特定场景下，企业可能会选择自己实现分库分表逻辑。这种做法的好处是可以完全控制整个流程，但缺点是需要投入大量的时间和精力去维护这些逻辑，而且容易出现各种边界情况的问题。
  4. 云服务提供的解决方案：
    • 对于使用云服务的企业来说，云平台通常会提供一整套的解决方案，包括自动化的分库分表、负载均衡等。例如，阿里云的DRDS就是一个典型的代表，它可以帮助用户轻松地管理和扩展数据库。
    • 云平台的优势在于它们通常会有专业的团队来维护和更新，减轻了企业的运维负担。

总的来说，ShardingSphere由于其强大的功能和灵活性，在很多场景下成为了首选。而MyCat则因其轻量级的特点，在一些中小企业或者对性能要求不是很高的项目中也有一定的使用率。当然，具体选择哪种方案还是要根据项目的实际情况来定。

ShardingSphere介绍

Apache ShardingSphere 是一款分布式的数据库生态系统， 可以将任意数据库转换为分布式数据库，并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。

Apache ShardingSphere 设计哲学为 Database Plus，旨在构建异构数据库上层的标准和生态。 它关注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。 它站在数据库的上层视角，关注它们之间的协作多于数据库自身。

官方文档：shardingsphere.apache.org/document/cu…

Apache ShardingSphere 由 ShardingSphere-JDBC 和 ShardingSphere-Proxy组成。

ShardingSphere-JDBC

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

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

如下图：

image-20241003211808750.png

ShardingSphere-JDBC是一个框架，对jdbc访问数据库进行了封装，实现了分库分表的功能。

Governance Center的作用有点类似于微服务架构中的配置中心

ShardingSphere-Proxy

ShardingSphere-Proxy 定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。 目前提供 MySQL 和 PostgreSQL 协议，透明化数据库操作，对 DBA 更加友好。

  • 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用；
  • 兼容 MariaDB 等基于 MySQL 协议的数据库，以及 openGauss 等基于 PostgreSQL 协议的数据库；
  • 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端，如：MySQL Command Client, MySQL Workbench, Navicat 等。

如下图：

ShardingSphere-Proxy和MyCat的作用一样，是一个数据库代理，应用程序原来是直接访问数据库，现在通过访问ShardingSphere-Proxy实现对数据分库分表。

image-20241003211845558.png

哪个应用得更多？

ShardingSphere-JDBC 和 ShardingSphere-Proxy哪个应用的更多？

实际上，选择哪一个取决于具体的应用场景和技术背景。如果应用程序已经使用了Spring框架，并且愿意在应用程序内部做少量的配置修改，那么ShardingSphere-JDBC是一个不错的选择。相反，如果希望保持应用程序代码不变，或者应用程序本身不适合修改JDBC访问逻辑，那么ShardingSphere-Proxy可能更适合。

在实际应用中，ShardingSphere-JDBC因为其更简单的集成方式而被广泛应用，特别是在已有Spring框架的环境中。但是随着人们对非侵入式解决方案的需求增加，ShardingSphere-Proxy也逐渐受到了关注，尤其是在需要与多种不同应用程序集成的情况下。

本文讲解ShardingSphere-JDBC的应用方法。

ShardingSphere-JDBC入门

本节我们对订单库进行分库分表，通过快速入门程序的开发，快速体验ShardingSphere-JDBC的使用 方法。

开发流程是：

先创建一个普通的SpringBoot工程，集成 Mybatis-Plus，可以实现向数据库表插入数据。

再改造为使用ShardingSphere-JDBC对数据库分库分表。

创建数据库

创建数据库：shardingsphere-test-01、shardingsphere-test-02

分别在这两个数据库中创建t_order_1、t_order_2表，这两个表就是对订单表的水平分表。

运行下边的脚本：

DROP TABLE IF EXISTS `t_order_1`;
CREATE TABLE `t_order_1`
(
    `order_id` bigint(20)                                             NOT NULL COMMENT '订单id',
    `price`    decimal(10, 2)                                         NOT NULL COMMENT '订单价格',
    `user_id`  bigint(20)                                             NOT NULL COMMENT '下单用户id',
    `status`   varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '订单状态',
    PRIMARY KEY (`order_id`) USING BTREE
) ENGINE = InnoDB
  CHARACTER SET = utf8
  COLLATE = utf8_general_ci
  ROW_FORMAT = Dynamic;
DROP TABLE IF EXISTS `t_order_2`;
CREATE TABLE `t_order_2`
(
    `order_id` bigint(20)                                             NOT NULL COMMENT '订单id',
    `price`    decimal(10, 2)                                         NOT NULL COMMENT '订单价格',
    `user_id`  bigint(20)                                             NOT NULL COMMENT '下单用户id',
    `status`   varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '订单状态',
    PRIMARY KEY (`order_id`) USING BTREE
) ENGINE = InnoDB
  CHARACTER SET = utf8
  COLLATE = utf8_general_ci
  ROW_FORMAT = Dynamic;

创建SpringBoot工程

创建一个SpringBoot工程集成MyBatis-PLUS。

过程略。

实现分库分表

添加ShardingSphere-JDBC依赖

下边集成 ShardingSphere-JDBC实现分库分表。

shardingsphere-jdbc用5.4.0版本

添加shardingsphere-jdbc依赖

<properties>
    <java.version>1.8</java.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <spring-boot.version>2.7.10</spring-boot.version>
    <shardingsphere-jdbc.version>5.4.0</shardingsphere-jdbc.version>
    <snakeyaml.version>1.33</snakeyaml.version>
    <mybatis-plus.version>3.4.3.2</mybatis-plus.version>
</properties>
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core</artifactId>
    <version>${shardingsphere-jdbc.version}</version>
</dependency>
<dependency>
    <groupId>org.yaml</groupId>
    <artifactId>snakeyaml</artifactId>
    <version>${snakeyaml.version}</version>
</dependency>

配置专属JDBC驱动

原来我们在application.yaml中配置的JDBC驱动如下：

  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://192.168.101.68:3306/shardingsphere-test-01?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai&stringtype=unspecified
    username: root
    password: mysql

集成ShardingSphere-JDBC需要修改为ShardingSphere-JDBC提供的JDBC驱动。

  datasource:
#    driver-class-name: com.mysql.cj.jdbc.Driver
#    url: jdbc:mysql://192.168.101.68:3306/shardingsphere-test-01?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai&stringtype=unspecified
    driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver
    url: jdbc:shardingsphere:classpath:shardingsphere-jdbc-dev.yml

配置分库分表策略

下边配置shardingsphere-jdbc-dev.yml文件，在此文件配置分库分表的策略。

配置数据源

首先配置数据源，因为目标是分两个数据库，所以配置两个数据源。

在resources下创建shardingsphere-jdbc-dev.yml文件，配置内容如下：

dataSources:
  db-orders-0:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    jdbcUrl: jdbc:mysql://192.168.101.68:3306/shardingsphere-test-01?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
    username: root
    password: mysql
  db-orders-1:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    jdbcUrl: jdbc:mysql://192.168.101.68:3306/shardingsphere-test-02?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
    username: root
    password: mysql

配置数据分片规则

下边配置数据分片规则，非常重要。

分片规则流程：

首先配置逻辑表，在逻辑表中配置数据结点、分表策略和分库策略。

配置逻辑表

参考此文档查看配置项的意义：shardingsphere.apache.org/document/cu…

rules:
- !SHARDING
  tables:
    t_order:
      actualDataNodes: db-orders-${0..1}.t_order_${1..2}
      tableStrategy:
        standard:
          shardingColumn: id
          shardingAlgorithmName: orders_table_inline
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: orders_database_inline

t_order：逻辑表名，与模型类中指定的表名一致：

@TableName("t_order")
public class Order implements Serializable {

actualDataNodes: 配置实际数据结点，由数据源+真实表名组成

tableStrategy：分表策略

shardingColumn：指定分片键，上边指定分片键为id表示根据主键进行水平分表。

​ shardingAlgorithmName：分片算法名称，自定义名称，下边会单独定义此算法。

databaseStrategy：分库策略

shardingColumn：指定分片键，上边指定分片键为user_id表示根据user_id进行分库。

　shardingAlgorithmName：分片算法名称，自定义名称，下边会单独定义此算法。

配置分库分表算法

与tables平级，配置shardingAlgorithms。

内容如下：

rules:
- !SHARDING
  tables:
    t_order:
      actualDataNodes: db-orders-${0..1}.t_order_${1..2}
      tableStrategy:
        standard:
          shardingColumn: id
          shardingAlgorithmName: orders_table_inline
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: orders_database_inline
  shardingAlgorithms:
    # 订单-分库算法
    orders_database_inline:
      type: INLINE
      props:
        # 分库算法表达式
        algorithm-expression: db-orders-${user_id % 2}
        # 分库支持范围查询
        allow-range-query-with-inline-sharding: true
    # 订单-分表算法
    orders_table_inline:
      type: INLINE
      props:
        # 分表算法表达式
        algorithm-expression: t_order_${id % 2 + 1}
        # 允许范围查询
        allow-range-query-with-inline-sharding: true

orders_database_inline：分库算法名称，对应上边配置的shardingAlgorithmName: orders_database_inline。

algorithm-expression: db-orders-{user_id % 2}: 根据 db-orders-{user_id % 2}表达式决定数据库

举例：user_id为1，通过计算user_id % 2得出1，数据库为db-orders-1

​ user_id为2，通过计算user_id % 2得出0，数据库为db-orders-0

orders_table_inline：分表算法名称，对应上边配置的shardingAlgorithmName: orders_table_inline

algorithm-expression: t_order_{id % 2 + 1}: 根据 t_order_{id % 2 + 1}表达决定实际的表名。

举例：id为1，通过计算id % 2 + 1得出2，表名为：t_order_2

​ id为2，通过计算id % 2 + 1得出1，表名为：t_order_1

参考文档：shardingsphere.apache.org/document/cu…

完整的配置文件内容如下：

dataSources:
  db-orders-0:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    jdbcUrl: jdbc:mysql://192.168.101.68:3306/shardingsphere-test-01?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
    username: root
    password: mysql
  db-orders-1:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    jdbcUrl: jdbc:mysql://192.168.101.68:3306/shardingsphere-test-02?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
    username: root
    password: mysql
rules:
- !TRANSACTION
  defaultType: BASE
- !SHARDING
  tables:
    t_order:
      actualDataNodes: db-orders-${0..1}.t_order_${1..2}
      tableStrategy:
        standard:
          shardingColumn: id
          shardingAlgorithmName: orders_table_inline
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: orders_database_inline
  shardingAlgorithms:
    # 订单-分库算法
    orders_database_inline:
      type: INLINE
      props:
        # 分库算法表达式
        algorithm-expression: db-orders-${user_id % 2}
        # 分库支持范围查询
        allow-range-query-with-inline-sharding: true
    # 订单-分表算法
    orders_table_inline:
      type: INLINE
      props:
        # 分表算法表达式
        algorithm-expression: t_order_${id % 2 + 1}
        # 允许范围查询
        allow-range-query-with-inline-sharding: true
  # id生成器
  keyGenerators:
    snowflake:
      type: SNOWFLAKE
props:
  sql-show: true

插入测试

首先向订单表插入10条数据，将user_id固定为1，根据分库策略数据将写入db-orders-1数据库。

根据 t_order_${id % 2 + 1}可知，根据订单id决定插入的表，订单id为偶数则插入t_order_1，奇数则插入t_order_2表。

观察日志：

首先解析逻辑SQL，现根据分片规则生成真实SQL。

2024-09-26 14:05:58.239  INFO 15532 --- [           main] ShardingSphere-SQL                       : Logic SQL: INSERT INTO t_order  ( id,
user_id,
price,
status )  VALUES  ( ?,
?,
?,
? )
2024-09-26 14:05:58.239  INFO 15532 --- [           main] ShardingSphere-SQL                       : Actual SQL: db-orders-0 ::: INSERT INTO t_order_1  ( id,
user_id,
price,
status )  VALUES  (?, ?, ?, ?) ::: [1839184587743883266, 2, 5.0, WAIT_PAY]
...

通过日志可以发现id为奇数的被插入到t_order_2表，为偶数的被插入到t_order_1表，达到预期目标。

再向订单表插入10条数据，将user_id固定为2, 根据分库策略数据将写入db-orders-0数据库。

请自行进行测试并观察结果是否符合预期。

查询测试

编写测试方法：

根据订单id进行查询。

@Test
public void testSelect(){
   //订单id
    Long id = 1L;
   //根据订单id和用户id查询订单
    List<Order> orders = orderMapper.selectList(new LambdaQueryWrapper<Order>()
            .eq(Order::getId, id)
            );
    System.out.println(orders);
}

运行测试观察日志：

2024-09-26 15:58:23.734  INFO 41948 --- [           main] ShardingSphere-SQL                       : Logic SQL: SELECT  id,user_id,price,status  FROM t_order 
 
 WHERE (id = ?)
2024-09-26 15:58:23.734  INFO 41948 --- [           main] ShardingSphere-SQL                       : Actual SQL: db-orders-0 ::: SELECT  id,user_id,price,status  FROM t_order_2 
 
 WHERE (id = ?) ::: [1]
2024-09-26 15:58:23.734  INFO 41948 --- [           main] ShardingSphere-SQL                       : Actual SQL: db-orders-1 ::: SELECT  id,user_id,price,status  FROM t_order_2 
 
 WHERE (id = ?) ::: [1]

为什么最终执行两条SQL？

因为ShardingSphere-JDBC也不清楚id为1数据在哪个数据库，所以会从两个数据库都去查询。

如果查询代码改为如下：

@Test
public void testSelect(){
   //订单id
    Long id = 1L;
    //用户id
    Long userId = 2L;
   //根据订单id和用户id查询订单
    List<Order> orders = orderMapper.selectList(new LambdaQueryWrapper<Order>()
            .eq(Order::getId, id)
            .eq(Order::getUserId, userId));
    System.out.println(orders);
}

请自己运行测试，观察日志，什么生成几条SQL呢？ 思考原因。

总结

到这里使用ShardingSphere-JDBC对MySQL分库分表的流程我们就介绍完了，下边划重点了：

如何使用ShardingSphere-JDBC实现分表分表？

  1. 配置ShardingSphere-JDBC提供的JDBC驱动。

  2. 配置分库分表策略

    配置数据源

    配置逻辑表

    配置分库分表算法

完整的源代码可以关注“黑马程序员-研究院”公众号获取。

如果你喜欢这篇文章，别忘了点赞、收藏、转发，分享给更多需要的小伙伴。

avatar
文章
阅读
粉丝