Spring Boot integrates ShardingSphere to realize data fragmentation (3) | Spring Cloud 42

I. Introduction

In the previous section, we had a basic understanding of data sharding through the following chapters:

Spring Boot integrates ShardingSphere to implement data fragmentation (1) | Spring Cloud 40

Spring Boot integrates ShardingSphere to realize data fragmentation (2) | Spring Cloud 41

Know the background and challenges of data sharding and the advantages and disadvantages of each data sharding type in business scenarios. Interested friends can browse by themselves.

Continuing from the last chapter, this chapter will demonstrate the integration of the following parts:

• Realize data sharding through Spring Bootintegration ShardingSphere-JDBC, show its integration steps and various considerations
• Give examples of sub-databases and sub-tables
• Show the data sharding algorithm used in daily development

Let's start with the text.

2. Introduction to ShardingSphere-JDBC

Apache ShardingSphereIt is a distributed database ecosystem, which can convert any database into a distributed database, and enhance the original database through data fragmentation, elastic scaling, encryption and other capabilities.

Apache ShardingSphereThe design philosophy Database Plusis to build standards and ecology on the upper layer of heterogeneous databases. It focuses on how to make full and reasonable use of the computing and storage capabilities of the database, rather than implementing a brand new database. It stands at the upper level of the database and pays more attention to the collaboration between them than the database itself.

ShardingSphere-JDBCPositioned as a lightweight Javaframework , it provides additional services at the layerJava of . JDBCIt uses the client to directly connect to the database and provides services in the form of jarpackages without additional deployment and dependencies. It can be understood as an enhanced version of JDBCthe driver, fully compatible JDBCwith and various ORMframeworks.

• Works with JDBCany ORMframework based on , such as: JPA, Hibernate, Mybatis, Spring JDBC Templateor directly using JDBC;
• Support any third-party database connection pool, such as: DBCP, C3P0, BoneCP, HikariCPetc.;

• Supports any database that implements JDBCthe specification , currently supports MySQL, PostgreSQL, Oracle, SQLServerand any database that can be JDBCaccessed .

For more ShardingSphereintroduction, please see the official website: https://shardingsphere.apache.org/document/current/en/overview/

2.1 Core Concepts

2.1.1 Table

Tables are a key concept for transparent data sharding. Apache ShardingSphereBy providing a variety of table types, it can adapt to the data fragmentation requirements in different scenarios.

2.1.1.1 Logic table

The logical name of the horizontal split database (table) of the same structure, which is the logical identifier of SQLthe table in . Example: The order data is split into 10tables , namely t_order_0to t_order_9, and their logical table names t_order.

2.1.1.2 Real table

Physical tables that actually exist in a horizontally split database. That is t_order_0to t_order_9.

2.1.1.3 Binding table

Refers to a set of shard tables with consistent sharding rules. When using a bound table for multi-table association query, you must use the shard key for association, otherwise Cartesian product association or cross-database association will occur, which will affect query efficiency.

For example: t_ordera table and t_order_itema table are both fragmented according to order_idand order_idassociated , then the two tables are bound table relationships. There will be no Cartesian product association in multi-table association query between bound tables, and the efficiency of association query will be greatly improved. For example, if SQLis :

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

When the binding table relationship is not configured, assuming that the shard order_idkey 10routes the value to the 0shard and 11routes the value to the 1shard , then SQLthere should be 4items after the route, and they are presented as a Cartesian product:

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

After configuring the binding table relationship and using order_idfor association, the routing SQLshould be 2items :

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

t_orderThe table ShardingSpherewill be used as the main table of the entire binding table because of the specified fragmentation conditions. All routing calculations will only use the strategy of the main table, then the fragmentation calculation of t_order_itemthe table will use t_orderthe conditions of .

2.1.1.4 Broadcast table

Refers to the tables that exist in all sharded data sources, and the table structure and its data are completely consistent in each database. It is suitable for scenarios where the amount of data is not large and needs to be associated with tables of massive data, such as dictionary tables.

2.1.1.5 Single table

Refers to the only table that exists in all sharded data sources. It is suitable for tables with a small amount of data and no need for fragmentation.

2.1.2 Data Nodes

The smallest unit of data sharding consists of a data source name and a real table. Example: ds_0.t_order_0. The mapping relationship between logical tables and real tables can be divided into two forms: uniform distribution and custom distribution.

2.1.2.1 Uniform distribution

It means that the data tables are evenly distributed in each data source, for example:

db0
  ├── t_order0
  └── t_order1
db1
  ├── t_order0
  └── t_order1

The configuration of the data node is as follows:

db0.t_order0, db0.t_order1, db1.t_order0, db1.t_order1

2.1.2.2 Custom distribution

Refers to the data table presenting a distribution with specific rules, for example:

db0
  ├── t_order0
  └── t_order1
db1
  ├── t_order2
  ├── t_order3
  └── t_order4

The configuration of the data node is as follows:

db0.t_order0, db0.t_order1, db1.t_order2, db1.t_order3, db1.t_order4

2.1.3 Fragmentation

2.1.3.1 Shard key

The database field used to split the database (table) horizontally.

Example: If the mantissa of the order primary key in the order table is modulo-sharded, the order primary key is a fragment field.

SQLIf there is no fragmentation field in , full routing will be performed and the performance will be poor. In addition to support for single sharding fields, Apache ShardingSpheresharding based on multiple fields is also supported.

2.1.3.2 Fragmentation algorithm

Algorithm for sharding data, supports =、>=、<=、>、<、BETWEENand INfor sharding. Fragmentation algorithms can be implemented by developers themselves, or they can use Apache ShardingSpherethe built-in slicing algorithm syntax sugar, which is very flexible.

2.1.3.3 Automatic Fragmentation Algorithm

Fragmentation algorithm syntactic sugar, used to conveniently host all data nodes, users do not need to pay attention to the physical distribution of real tables. Including the implementation of commonly used sharding algorithms such as modulo, hash, range, and time.

2.1.3.4 Custom Fragmentation Algorithm

Provide an interface to allow application developers to implement sharding algorithms that are closely related to business implementation, and allow users to manage the physical distribution of real tables by themselves. The custom sharding algorithm is further divided into:

• Standard Fragmentation Algorithm

  It is used to =、IN、BETWEEN AND、>、<、>=、<=handle .

• Composite Fragmentation Algorithm

  It is used to handle the scenario where multiple keys are used as the sharding key for sharding. The logic of including multiple sharding keys is more complicated, and application developers need to handle the complexity by themselves.

• HintFragmentation Algorithm

  Used to handle scenarios where Hintrow .

2.1.3.5 Fragmentation strategy

Contains sharding keys and sharding algorithms, which are separated independently due to the independence of sharding algorithms. What can really be used for sharding operations is the sharding key +sharding algorithm, that is, the sharding strategy.

2.1.3.6 Force fragment routing

For scenarios where the fragment field is not determined by SQLbut other external conditions, you can use to SQL Hintinject the fragment value.

Example: The database is divided according to the employee login primary key, but there is no such field in the database. SQL HintIt supports two ways of using Java APIand SQLcommenting. For details, see Enforcing Fragment Routing.

2.1.4 Line expressions

Line expressions are to solve the two main problems of configuration simplification and integration.

In the cumbersome configuration of data sharding rules, with the increase of data nodes, a large number of repeated configurations make the configuration itself difficult to maintain. The workload of data node configuration can be effectively simplified through row expressions.

For common sharding algorithms, using Javacode implementation does not help the unified management of configuration. Writing sharding algorithms through line expressions can effectively store rule configurations together, making it easier to browse and store.

The use of line expressions is very intuitive, you only need to use or to identify line expressions ${ expression }in the configuration . Currently, it supports the configuration of data nodes and sharding algorithms. The content of the line expression uses the syntax of , and all operations that can be supported can be supported by the line expression. For example:$->{ expression }GroovyGroovy

${begin..end}Represents a range interval ${[unit1, unit2, unit_x]}Represents an enumerated value

If there are multiple consecutive ${ expression }or $->{ expression }expressions in the row expression, the final result of the entire expression will be Cartesian combined according to the results of each sub-expression.

For example, the following line expression:

${
   
   ['online', 'offline']}_table${
   
   1..3}

will eventually resolve to:

online_table1, online_table2, online_table3, offline_table1, offline_table2, offline_table3

2.1.5 Distributed primary key

In traditional database software development, the primary key automatic generation technology is a basic requirement. Each database also provides corresponding support for this requirement, such MySQLas auto-increment key and Oracleauto-increment sequence.

After data fragmentation, it is very difficult to generate a global unique primary key for different data nodes. The auto-increment keys between different actual tables in the same logical table produce duplicate primary keys because they cannot be aware of each other. Although collisions can be avoided by constraining the initial value and step size of the auto-increment primary key, additional operation and maintenance rules need to be introduced, making the solution lack of integrity and scalability.

At present, there are many third-party solutions that can perfectly solve this problem, such as UUIDrelying specific algorithms to self-generate unique keys, or generating services by introducing primary keys.

In order to facilitate the use of users and meet the needs of different users in different usage scenarios, Apache ShardingSpherenot only a built-in distributed primary key generator is provided, for example UUID, SNOWFLAKE, but also the interface of the distributed primary key generator is extracted, so that users can implement self-defined self-incrementing primary keys Builder.

3. Example of sub-database and sub-table

3.1 Overall structure of sub-database and sub-table

3.1.1 Data source ds1

database address	data source name	real table name	logical table name	business description
192.168.0.35	ds1	t_goods_0	t_goods	Commodity table-sub-library/sub-list
192.168.0.35	ds1	t_goods_1	t_goods	Commodity table-sub-library/sub-list
192.168.0.35	ds1	t_order_0	t_order	Order table-sub-library/sub-table
192.168.0.35	ds1	t_order_1	t_order	Order table-sub-library/sub-table
192.168.0.35	ds1	t_order_item_0	t_order_item	Order Details - Sub-library/Sub-table
192.168.0.35	ds1	t_order_item_1	t_order_item	Order Details - Sub-library/Sub-table
192.168.0.35	ds1	sys_dict	sys_dict	System dictionary table - single table
192.168.0.35	ds1	sys_dict_item	sys_dict_item	System dictionary sub-table-single table

3.1.2 Data source ds2

database address	data source name	real table name	logical table name	business description
192.168.0.46	ds2	t_goods_0	t_goods	Commodity table-sub-library/sub-list
192.168.0.46	ds2	t_goods_1	t_goods	Commodity table-sub-library/sub-list
192.168.0.46	ds2	t_order_0	t_order	Order table-sub-library/sub-table
192.168.0.46	ds2	t_order_1	t_order	Order table-sub-library/sub-table
192.168.0.46	ds2	t_order_item_0	t_order_item	Order Details - Sub-library/Sub-table
192.168.0.46	ds2	t_order_item_1	t_order_item	Order Details - Sub-library/Sub-table
192.168.0.46	ds2	sys_dict	sys_dict	System dictionary table - single table
192.168.0.46	ds2	sys_dict_item	sys_dict_item	System dictionary sub-table-single table

3.1.3 Logical commodity table t_goods

-- ----------------------------
-- Table structure for t_goods_0
-- ----------------------------
DROP TABLE IF EXISTS `t_goods_0`;
CREATE TABLE `t_goods_0`  (
  `goods_id` bigint NOT NULL,
  `goods_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '商品名称',
  `main_class` bigint NULL DEFAULT NULL COMMENT '商品大类数据字典',
  `sub_class` bigint NULL DEFAULT NULL COMMENT '商品小类数据字典',
  PRIMARY KEY (`goods_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Table structure for t_goods_1
-- ----------------------------
DROP TABLE IF EXISTS `t_goods_1`;
CREATE TABLE `t_goods_1`  (
  `goods_id` bigint NOT NULL,
  `goods_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '商品名称',
  `main_class` bigint NULL DEFAULT NULL COMMENT '商品大类数据字典',
  `sub_class` bigint NULL DEFAULT NULL COMMENT '商品小类数据字典',
  PRIMARY KEY (`goods_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

3.1.4 Logical order table t_order

-- ----------------------------
-- Table structure for t_order_0
-- ----------------------------
DROP TABLE IF EXISTS `t_order_0`;
CREATE TABLE `t_order_0`  (
  `order_id` bigint NOT NULL AUTO_INCREMENT,
  `create_by` bigint NULL DEFAULT NULL COMMENT '下单人',
  `create_time` datetime NULL DEFAULT NULL COMMENT '下单时间',
  PRIMARY KEY (`order_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Table structure for t_order_1
-- ----------------------------
DROP TABLE IF EXISTS `t_order_1`;
CREATE TABLE `t_order_1`  (
  `order_id` bigint NOT NULL AUTO_INCREMENT,
  `create_by` bigint NULL DEFAULT NULL COMMENT '下单人',
  `create_time` datetime NULL DEFAULT NULL COMMENT '下单时间',
  PRIMARY KEY (`order_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

3.1.5 Logical Order Details

-- ----------------------------
-- Table structure for t_order_item_0
-- ----------------------------
DROP TABLE IF EXISTS `t_order_item_0`;
CREATE TABLE `t_order_item_0`  (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `goods_id` bigint NOT NULL COMMENT '商品ID',
  `goods_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
  `create_by` bigint NULL DEFAULT NULL COMMENT '下单人',
  `create_time` datetime NULL DEFAULT NULL COMMENT '下单时间',
  PRIMARY KEY (`order_item_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Table structure for t_order_item_1
-- ----------------------------
DROP TABLE IF EXISTS `t_order_item_1`;
CREATE TABLE `t_order_item_1`  (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `goods_id` bigint NOT NULL COMMENT '商品ID',
  `goods_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
  `create_by` bigint NULL DEFAULT NULL COMMENT '下单人',
  `create_time` datetime NULL DEFAULT NULL COMMENT '下单时间',
  PRIMARY KEY (`order_item_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

3.1.6 System dictionary table

DROP TABLE IF EXISTS `sys_dict`;
CREATE TABLE `sys_dict`  (
  `id` bigint(18) NOT NULL AUTO_INCREMENT COMMENT '字典ID',
  `dict_code` varchar(55) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典代码',
  `dict_name` varchar(125) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典名称',
  `dict_status` tinyint(4) NOT NULL DEFAULT 0 COMMENT '字典状态\r\n0： 停用\r\n1： 启用',
  `dict_type` tinyint(4) NULL DEFAULT 0 COMMENT '字典类型(0-系统字典 5-公共 9-解析字典)',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `idx`(`dict_code`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = '系统-字典表' ROW_FORMAT = Dynamic;

DROP TABLE IF EXISTS `sys_dict_item`;
CREATE TABLE `sys_dict_item`  (
  `id` bigint(18) NOT NULL AUTO_INCREMENT COMMENT '字典子项id',
  `dict_id` bigint(18) NOT NULL COMMENT '字典ID',
  `dict_item_code` varchar(55) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典子项代码',
  `dict_item_value` varchar(125) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典子项展示值',
  `dict_item_desc` varchar(125) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT '' COMMENT '字典子项描述',
  `item_status` tinyint(1) NOT NULL DEFAULT 0 COMMENT '字典子项状态\r\n0： 停用\r\n1： 启用',
  `item_attrs` varchar(1024) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '自定义json字符串属性',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = '系统-字典子项表' ROW_FORMAT = Dynamic;

3.2 Project structure

3.2.1 Overall project structure

3.2.2 Maven dependencies

shading-sphere/shading-databases-tables/pom.xml：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>shading-sphere</artifactId>
        <groupId>com.gm</groupId>
        <version>0.0.1-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>shading-databases-tables</artifactId>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>com.mysql</groupId>
            <artifactId>mysql-connector-j</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId>
            <version>5.2.1</version>
        </dependency>

        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-boot-starter</artifactId>
            <version>3.5.3.1</version>
        </dependency>

        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-generator</artifactId>
            <version>3.5.3.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.velocity</groupId>
            <artifactId>velocity-engine-core</artifactId>
            <version>2.3</version>
        </dependency>

        <dependency>
            <groupId>org.yaml</groupId>
            <artifactId>snakeyaml</artifactId>
            <version>1.33</version>
        </dependency>

        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>2.0.25</version>
        </dependency>

    </dependencies>

</project>

• shardingsphere-jdbc-core-spring-boot-starteruse version5.2.1
• JDBCThe ORMframe selectionmybatis-plus

3.2.3 Configuration file

shading-sphere/shading-databases-tables/src/main/resources/application.yml：

server:
  port: 8844

spring:
  application:
    name: @artifactId@
  shardingsphere:
    # 数据源配置
    datasource:
      names: ds1,ds2
      ds1:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://192.168.0.35:3306/db1?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
        username: root
        password: '1qaz@WSX'
      ds2:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://192.168.0.46:3306/db2?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
        username: root
        password: '1qaz@WSX'

    # 定义规则
    rules:
      sharding:
        # 数据分片规则配置
        tables:
          # 指定某个表的分片配置，逻辑表名，此商品表按照大类进行分库，按照小类进行分表
          t_goods:
            # 这个配置是告诉sharding有多少个库和多少个表及所在实际的数据库节点，由数据源名 + 表名组成（参考 Inline 语法规则）
            actual-data-nodes: ds$->{
    
    1..2}.t_goods_$->{
    
    0..1}
            # 配置库分片策略
            database-strategy:
              # 用于单分片键的标准分片场景
              standard:
                # 分片列名称
                sharding-column: main_class
                # 分片算法名称
                sharding-algorithm-name: t_goods_database_inline
            # 配置表分片策略
            table-strategy:
              # 用于单分片键的标准分片场景
              standard:
                # 分片列名称
                sharding-column: sub_class
                # 分片算法名称
                sharding-algorithm-name: t_goods_table_inline
            # 分布式序列策略
            key-generate-strategy:
              # 自增列名称，缺省表示不使用自增主键生成器
              column: goods_id
              # 分布式序列算法名称
              key-generator-name: snowflake
          # 指定某个表的分片配置，逻辑表名，此订单表缺省分库策略表示使用默认分库策略，按照订单ID进行分表
          t_order:
            # 这个配置是告诉sharding有多少个库和多少个表及所在实际的数据库节点，由数据源名 + 表名组成（参考 Inline 语法规则）
            actual-data-nodes: ds$->{
    
    1..2}.t_order_$->{
    
    0..1}
            # 配置表分片策略
            table-strategy:
              # 用于单分片键的标准分片场景
              standard:
                # 分片列名称
                sharding-column: order_id
                # 分片算法名称
                sharding-algorithm-name: t_order_table_inline
            # 分布式序列策略
            key-generate-strategy:
              # 自增列名称，缺省表示不使用自增主键生成器
              column: order_id
              # 分布式序列算法名称
              key-generator-name: snowflake
          # 指定某个表的分片配置，逻辑表名，此订单明细表缺省分库策略表示使用默认分库策略，按照订单ID进行分表
          t_order_item:
            # 这个配置是告诉sharding有多少个库和多少个表及所在实际的数据库节点，由数据源名 + 表名组成（参考 Inline 语法规则）
            actual-data-nodes: ds$->{
    
    1..2}.t_order_item_$->{
    
    0..1}
            # 配置表分片策略
            table-strategy:
              # 用于单分片键的标准分片场景
              standard:
                # 分片列名称
                sharding-column: order_id
                # 分片算法名称
                sharding-algorithm-name: t_order_order_item_inline
            # 分布式序列策略
            key-generate-strategy:
              # 自增列名称，缺省表示不使用自增主键生成器
              column: order_item_id
              # 分布式序列算法名称
              key-generator-name: snowflake
        # 分片算法配置
        sharding-algorithms:
          # 分片算法名称
          t_goods_table_inline:
            # 分片算法类型
            type: INLINE
            # 分片算法属性配置
            props:
              algorithm-expression: t_goods_${
    
    sub_class % 2}
          # 分片算法名称
          t_goods_database_inline:
            # 分片算法类型
            type: INLINE
            # 分片算法属性配置
            props:
              algorithm-expression: ds$->{
    
    main_class % 2 + 1}
          # 分片算法名称
          t_order_table_inline:
            # 分片算法类型
            type: INLINE
            # 分片算法属性配置
            props:
              algorithm-expression: t_order_${
    
    order_id % 2}
          # 分片算法名称
          t_order_order_item_inline:
            # 分片算法类型
            type: INLINE
            # 分片算法属性配置
            props:
              algorithm-expression: t_order_item_${
    
    order_id % 2}
          # 分片算法名称
          default_database_inline:
            # 分片算法类型
            type: INLINE
            # 分片算法属性配置
            props:
              algorithm-expression: ds$->{
    
    create_by % 2 + 1}
        # 分布式序列算法配置（如果是自动生成的，在插入数据的sql中就不要传id，null也不行，直接插入字段中就不要有主键的字段）
        keyGenerators:
          # 分布式序列算法名称
          snowflake:
            # 分布式序列算法类型
            type: SNOWFLAKE
        # 绑定表规则列表
        binding-tables:
          # 分片规则一致的一组分片表防在一起
          - t_order,t_order_item
        broadcast-tables:
          - sys_dict,sys_dict_item
        # 默认数据库分片策略，当分库策略缺省表示使用默认分库策略
        defaultDatabaseStrategy:
          # 用于单分片键的标准分片场景
          standard:
            # 分片列名称
            sharding-column: create_by
            # 分片算法名称
            sharding-algorithm-name: default_database_inline
    props:
      sql-show: true #显示sql

mybatis:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

Configuration brief description:

• Commodity logic table t_goods:
  • Segment the library according to the commodity category modulo sharding algorithm
  • Segment tables according to the modulo fragmentation algorithm of commodity subcategories
• Order logic table t_order:
  • Segment database according to the single-person modulo sharding algorithm
  • Divide tables according to the order ID modulo fragmentation algorithm
• Order detail logic table t_order_item:
  • Segment database according to the single-person modulo sharding algorithm
  • Divide tables according to the order ID modulo fragmentation algorithm
• Binding table: t_order, t_order_item(a group of shard tables with the same sharding rules are kept together)
• broadcast table: sys_dict,sys_dict_item
• sqlDistributed sequence: use the snowflake algorithm (for distributed sequences, do not pass the corresponding column name when inserting data , nulland it will not work)

For more data sharding configuration items , please refer to the official website: https://shardingsphere.apache.org/document/5.2.1/cn/user-manual/shardingsphere-jdbc/spring-boot-starter/rules/sharding/

ShardingSphereBuilt-in provides a variety of sharding algorithms , please refer to the official website:
https://shardingsphere.apache.org/document/5.2.1/cn/user-manual/common-config/builtin-algorithm/sharding/

ShardingSphereBuilt-in provides a variety of distributed sequence algorithms , please refer to the official website:
https://shardingsphere.apache.org/document/5.2.1/cn/user-manual/common-config/builtin-algorithm/keygen/

For the complete source code of the above example, please see: https://gitee.com/gm19900510/springboot-cloud-example.git