一口气搞懂分库分表 12 种分片算法，大厂都在用

川长思鸟来 2024-05-01 16:28 8阅读 0赞

### 前言 ###

本文是《ShardingSphere5.x分库分表原理与实战》系列的第五篇文章，我们一起梳理下`ShardingSphere`框架中的核心部分**分片策略**和**分片算法**，其内部针为我们提供了多种分片策略和分片算法，来应对不同的业务场景，本着拿来即用的原则。

这次将详细介绍如何在`ShardingSphere-jdbc`中实战 5 种分片策略和 12 种分片算法，自定义分片算法，比较它们的应用场景以及优劣。

![图片][9647b3b0a70d38131c41d77c9d37240a.png]

> 全部demo案例 **GitHub** 地址：https://github.com/chengxy-nds/Springboot-Notebook/tree/master/shardingsphere101/shardingsphere-algorithms

### 分片策略 ###

分片策略是`分片键`和`分片算法`的组合策略，真正用于实现数据分片操作的是分片键与相应的分片算法。在分片策略中，分片键确定了数据的拆分依据，分片算法则决定了如何对分片键值运算，将数据路由到哪个物理分片中。

由于分片算法的独立性，使得分片策略具有更大的灵活性和可扩展性。这意味着可以根据具体需求选择不同的分片算法，或者开发自定义的分片算法，以适应各种不同的分片场景。**在分表和分库时使用分片策略和分片算法的方式是一致的**。

> **注意**：如果在某种分片策略中使用了不受支持的SQL操作符，比如 MYSQL 某些函数等，那么系统将无视分片策略，进行全库表路由操作。这个在使用时要慎重！

`ShardingSphere`对外提供了`standard`、`complex`、`hint`、`inline`、`none`5种分片策略。不同的分片策略可以搭配使用不同的分片算法，这样可以灵活的应对复杂业务场景。

#### **标准分片策略** ####

标准分片策略（`standard`）适用于具有**单一分片键**的标准分片场景。该策略支持精确分片，即在SQL中包含`=`、`in`操作符，以及范围分片，包括`BETWEEN AND`、`>`、`<`、`>=`、`<=`等范围操作符。

该策略下有两个属性，分片字段`shardingColumn`和分片算法名`shardingAlgorithmName`。

spring:
      shardingsphere:
        rules:
          sharding:
            tables:
              t_order: # 逻辑表名称
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${1..10}
                # 分库策略
                databaseStrategy: # 分库策略
                  standard: # 用于单分片键的标准分片场景
                    shardingColumn: order_id # 分片列名称
                    shardingAlgorithmName: # 分片算法名称
               tableStrategy: # 分表策略，同分库策略

#### **行表达式分片策略** ####

行表达式分片策略（`inline`）适用于具有**单一分片键**的简单分片场景，支持SQL语句中`=`和`in`操作符。

它的配置相当简洁，该分片策略支持在配置属性`algorithm-expression`中书写`Groovy`表达式，用来定义对分片健的运算逻辑，无需单独定义分片算法了。

spring:
      shardingsphere:
        rules:
          sharding:
            tables:
              t_order: # 逻辑表名称
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${1..10}
                # 分库策略
                databaseStrategy: # 分库策略
                  inline:   # 行表达式类型分片策略
                    algorithm-expression: db$->{order_id % 2} Groovy表达式
                tableStrategy: # 分表策略，同分库策略

#### **复合分片策略** ####

复合分片策略（`complex`）适用于**多个分片键**的复杂分片场景，属性`shardingColumns`中多个分片健以逗号分隔。支持 SQL 语句中有`>`、`>=`、`<=`、`<`、`=`、`IN` 和 `BETWEEN AND` 等操作符。

比如：我们希望通过`user_id`和`order_id`等多个字段共同运算得出数据路由到具体哪个分片中，就可以应用该策略。

spring:
      shardingsphere:
        rules:
          sharding:
            tables:
              t_order: # 逻辑表名称
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${1..10}
                # 分库策略
                databaseStrategy: # 分库策略
                  complex: # 用于多分片键的复合分片场景
                    shardingColumns: order_id，user_id # 分片列名称，多个列以逗号分隔
                    shardingAlgorithmName: # 分片算法名称
                tableStrategy: # 分表策略，同分库策略

#### **Hint分片策略** ####

Hint强制分片策略相比于其他几种分片策略稍有不同，该策略无需配置分片健，由外部指定分库和分表的信息，可以让SQL在指定的分库、分表中执行。

使用场景：

*  分片字段不存在SQL和数据库表结构中，而存在于外部业务逻辑。
 *  强制在指定数据库进行某些数据操作。

比如，我们希望用`user_id`做分片健进行路由订单数据，但是`t_order`表中也没`user_id`这个字段啊，这时可以通过`Hint API`手动指定分片库、表等信息，强制让数据插入指定的位置。

spring:
      shardingsphere:
        rules:
          sharding:
            tables:
              t_order: # 逻辑表名称
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${1..10}
                # 分库策略
                databaseStrategy: # 分库策略
                  hint: # Hint 分片策略
                    shardingAlgorithmName: # 分片算法名称
                tableStrategy: # 分表策略，同分库策略

#### **不分片策略** ####

不分片策略比较好理解，设置了不分片策略，那么对逻辑表的所有操作将会执行全库表路由。

spring:
      shardingsphere:
        rules:
          sharding:
            tables:
              t_order: # 逻辑表名称
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${1..10}
                # 分库策略
                databaseStrategy: # 分库策略
                  none: # 不分片
               tableStrategy: # 分表策略，同分库策略

### 分片算法 ###

ShardingSphere 内置了多种分片算法，按照类型可以划分为`自动分片算法`、`标准分片算法`、`复合分片算法`和 `Hint 分片算法`，能够满足我们绝大多数业务场景的需求。

此外，考虑到业务场景的复杂性，内置算法也提供了自定义分片算法的方式，我们可以通过编写 Java代码来完成复杂的分片逻辑。下边逐个算法实践一下，看看每种算法的实际执行效果。

> **开始前，我要吐槽下官方文档，对于算法这种至关重要的内容，解释描述的过于潦草，对于新手入门不友好，学习成本偏高啊**

#### **准备工作** ####

给逻辑表配置完算法后，先执行创建表的SQL，这样就可以依据你的算法在db内快速生成分片表，所以不要总是问我要表结构了，哈哈哈。如果有不明白的小伙伴可以看我上一篇对于`autoTable`的介绍 [分库分表如何管理不同实例中几万张分片表？][Link 1]。

#### **自动分片算法** ####

##### 1、MOD #####

取模分片算法是内置的一种比较简单的算法，定义算法时类型`MOD`，表达式大致`（分片健/数据库实例） % sharding-count`，它只有一个 props 属性`sharding-count`代表分片表的数量。

![图片][9d4c9196e75ae8e85c1e4747c2687c3c.png]

这个 sharding-count 数量使用时有点小坑，比如`db0`和`db1`都有分片表`t_order_1`，那么实际上数量只能算一个。`YML`核心配置如下：

spring:
      shardingsphere:
        rules:
          sharding:
            # 自动分片表规则配置
            auto-tables:
              t_order:
                actual-data-sources: db$->{0..1}
                sharding-strategy:
                  standard:
                    sharding-column: order_date
                    sharding-algorithm-name: t_order_table_mod
            # 分片算法定义
            sharding-algorithms:
              t_order_table_mod:
                type: MOD # 取模分片算法
                props:
                  # 指定分片数量
                  sharding-count: 6
            tables:
              t_order: # 逻辑表名称
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                ....
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_table_mod

##### 2、HASH\_MOD #####

哈希取模分片算法是内置取模分片算法的一个升级版本，定义算法时类型`HASH_MOD`，也只有一个`props`属性`sharding-count`代表分片的数量。表达式`hash（分片健/数据库实例） % sharding-count`。

![图片][655498e8a88685497059a88bb0709133.png]

`YML`核心配置如下：

##### 3、VOLUME\_RANGE #####

基于分片容量的范围分片算法，依据数据容量来均匀分布到分片表中。

它适用于数据增长趋势相对均匀，按分片容量将数据均匀地分布到不同的分片表中，可以有效避免数据倾斜问题；由于数据已经被按照范围进行分片，支持频繁进行范围查询场景。

不仅如此，该算法支持动态的分片调整，可以根据实际业务数据的变化动态调整分片容量和范围，使得系统具备更好的扩展性和灵活性。

`VOLUME_RANGE`算法主要有三个属性：

![图片][8fad2a9a483c6a24d5dc6511fde3eace.png]

看完是不是一脸懵逼，上界下界都是什么含义，我们实际使用一下就清晰了。为`t_order`逻辑表设置`VOLUME_RANGE`分片算法，`range-lower`下界数为 2，`range-upper`上界数为 20，分量容量`sharding-volume` 10。

`yml`核心配置如下：

# 分片算法定义
    spring:
      shardingsphere:
        rules:
          sharding:
            # 自动分片表规则配置
            auto-tables:
              t_order:
                actual-data-sources: db$->{0..1}
                sharding-strategy:
                  standard:
                    sharding-column: order_date
                    sharding-algorithm-name: t_order_table_volume_range
            sharding-algorithms:
              t_order_table_volume_range:
                type: VOLUME_RANGE
                props:
                  range-lower: 2 # 范围下界，超过边界的数据会报错
                  range-upper: 20 # 范围上界，超过边界的数据会报错
                  sharding-volume: 10 # 分片容量
            tables:
              t_order: # 逻辑表名称
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                ....
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_table_volume_range

这个配置的意思就是说，分片健`t_order_id`的值在界值 \[range-lower，range-upper) 范围内，每个分片表最大存储 10 条数据；低于下界的值 `[ 1，2 )` 数据分布到 t\_order\_0，在界值范围内的数据 `[ 2，20 )` 遵循每满足 10 条依次放入 t\_order\_1、t\_order\_2；超出上界的数据`[ 20，∞ )` 即便前边的分片表里未满 10条剩下的也全部放在 t\_order\_3。

那么它的数据分布应该如下：

*  `[ 0，2 )`数据分布到 t\_order\_0
 *  `[ 2，12 )`数据分布到 t\_order\_1
 *  `[ 12，20 )`数据分布到 t\_order\_2
 *  `[ 20，∞ )`数据分布到 t\_order\_3

![图片][22680aaa78b791489d4bf08de0a67044.png]

基于分片容量的范围分片算法

接着准备插入40条数据，其中分片健字段`t_order_id`值从1～40，我们看到实际插入库的数据和上边配置的规则是一致的。超出`range-lower`、`range-upper`边界的部分数据，比如：`t_order_2`表未满 10条也不再插入，全部放入了`t_order_3`分片表中。

![图片][fce49baf782f4ee67cd1256803875d08.png]

##### 4、BOUNDARY\_RANGE #####

基于分片边界的范围分片算法，和分片容量算法不同，这个算法根据数据的取值范围进行分片，特别适合按数值范围频繁查询的场景。该算法只有一个属性`sharding-ranges`为分片健值的范围区间。

![图片][91034dc04acd8c40770dda9bf20412c1.png]

比如，我们配置`sharding-ranges=10,20,30,40`，它的范围默认是从 0开始，范围区间前闭后开。配置算法以后执行建表语句，生成数据节点分布如：

db0-
       ｜_t_order_0
       ｜_t_order_2
       ｜_t_order_4
    db1-
       ｜_t_order_1
       ｜_t_order_3

那么它的数据分布应该如下：

`[ 0，10 )`数据分布到t\_order\_0，

`[ 10，20 )`数据分布到t\_order\_1，

`[ 20，30 )`数据分布到t\_order\_2，

`[ 30，40 )`数据分布到t\_order\_3，

`[ 40，∞ )`数据分布到t\_order\_4。

![图片][7d9b72acb105d9dce0a3765b37ee50d2.png]

基于分片边界的范围分片算法

`BOUNDARY_RANGE`算法的`YML`核心配置如下：

也插入40条数据，其中分片健字段`t_order_id`值从1～40，和上边分析的数据分布结果大致相同。看到第一张分片表中 t\_order\_0 只有 9 条数据，这是因为咱们插入数据的分片健值是从 1 开始，但算法是从 0 开始计算。

![图片][d7dced7d641cbb01bc9fd7d804442710.png]

##### 5、AUTO\_INTERVAL #####

自动时间段分片算法，适用于以时间字段作为分片健的分片场景，和`VOLUME_RANGE`基于容量的分片算法用法有点类似，不同的是`AUTO_INTERVAL`依据时间段进行分片。主要有三个属性`datetime-lower`分片健值开始时间（下界）、`datetime-upper`分片健值结束时间（上界）、`sharding-seconds`单一分片表所能容纳的时间段。

![图片][8eae62d497af6bd0ec99c582157d137d.png]

这里分片健已经从`t_order_id`替换成了`order_date`。现在属性 datetime-lower 设为 2023-01-01 00:00:00，datetime-upper 设为 2025-01-01 00:00:00，`sharding-seconds`为 31536000 秒（一年）。策略配置上有些改动，将分库和分表的算法全替换成`AUTO_INTERVAL`。

`YML`核心配置如下：

spring:
      shardingsphere:
        rules:
          sharding:
            # 自动分片表规则配置
            auto-tables:
              t_order:
                actual-data-sources: db$->{0..1}
                sharding-strategy:
                  standard:
                    sharding-column: order_date
                    sharding-algorithm-name: t_order_table_auto_interval
            # 分片算法定义
            sharding-algorithms:
              # 自动时间段分片算法
              t_order_table_auto_interval:
                type: AUTO_INTERVAL
                props:
                  datetime-lower: '2023-01-01 00:00:00' # 分片的起始时间范围，时间戳格式：yyyy-MM-dd HH:mm:ss
                  datetime-upper: '2025-01-01 00:00:00' #  分片的结束时间范围，时间戳格式：yyyy-MM-dd HH:mm:ss
                  sharding-seconds: 31536000 # 单一分片所能承载的最大时间，单位：秒，允许分片键的时间戳格式的秒带有时间精度，但秒后的时间精度会被自动抹去
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                  standard:
                    sharding-column: order_date
                    sharding-algorithm-name: t_order_table_auto_interval
                # 分表策略
    #            table-strategy:
    #              standard:
    #                sharding-column: order_date
    #                sharding-algorithm-name: t_order_table_auto_interval

只要你理解了上边 `VOLUME_RANGE` 算法的数据分布规则，那么这个算法也很容易明白，分片健值在界值范围内 \[datetime-lower，datetime-upper) 遵循每满足 sharding-seconds 时间段的数据放入对应分片表，超出界值的数据上下顺延到其他分片中。

它的数据分布应该如下：

*  `[ 2023-01-01 00:00:00，2024-01-01 00:00:00 )`数据分布到 t\_order\_0，
 *  `[ 2024-01-01 00:00:00，2025-01-01 00:00:00 )`数据分布到 t\_order\_1，
 *  `[ 2025-01-01 00:00:00，2026-01-01 00:00:00 )`数据分布到 t\_order\_2。
 *  `[ 2026-01-01 00:00:00，∞ )`数据分布到 t\_order\_3。

为了方便测试，手动执行插入不同日期的数据，按照上边配置的规则应该`t_order_0`会有一条 23 年的数据，`t_order_1` 中有两条 24 年的数据，`t_order_2` 中有两条 25 年的数据，`t_order_3` 中有两条 26、27 年的数据。

// 放入 t_order_0 分片表
    INSERT INTO `t_order` VALUES (1, '2023-03-20 00:00:00', 1, '1', 1, 1.00);
    // 放入 t_order_1 分片表
    INSERT INTO `t_order` VALUES (2, '2024-03-20 00:00:00', 2, '2', 2,1.00);
    INSERT INTO `t_order` VALUES (3, '2024-03-20 00:00:00', 3, '3', 3, 1.00);
    // 放入 t_order_2 分片表
    INSERT INTO `t_order` VALUES (4,'2025-03-20 00:00:00',4, '4', 4, 1.00);
    INSERT INTO `t_order` VALUES (5,'2025-03-20 00:00:00',5, '5', 5,  1.00);
    // 放入 t_order_3 分片表
    INSERT INTO `t_order` VALUES (6,'2026-03-20 00:00:00',6, '6', 6,  1.00);
    INSERT INTO `t_order` VALUES (7,'2027-03-20 11:19:58',7, '7', 7,  1.00);

查看实际的数据分布情况和预想的结果完全一致，至此内置算法全部使用大成。

![图片][65a24c99672c5035d669114328a01178.png]

#### **标准分片算法** ####

##### 6、INLINE #####

行表达式分片算法，适用于比较简单的分片场景，利用`Groovy`表达式在算法属性内，直接书写分片逻辑，省却了配置和代码开发，只支持SQL语句中的 = 和 IN 的分片操作，只支持**单分片键**。

![图片][066d48523693bdc5ee3fafa52c4f5639.png]

该算法有两属性：

*  `algorithm-expression`：编写`Groovy`的表达式，比如: `t_order_$->{t_order_id % 3}` 表示根据分片健 t\_order\_id 取模获得 3 张 t\_order 分片表 t\_order\_0 到 t\_order\_2。
 *  `allow-range-query-with-inline-sharding`：由于该算法只支持含有 = 和 IN 操作符的SQL，一旦SQL使用了范围查询 >、< 等操作会报错。要想执行范围查询成功，该属性开启为`true`即可，一旦开启范围查询会无视分片策略，进行全库表路由查询，**这个要慎重开启**！

`YML`核心配置如下：

spring:
      shardingsphere:
        # 具体规则配置
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              # 标准分片算法
              # 行表达式分片算法
              t_order_table_inline:
                type: INLINE
                props:
                  algorithm-expression: t_order_$->{order_id % 3} # 分片算法的行表达式
                  allow-range-query-with-inline-sharding: false # 是否允许范围查询。注意：范围查询会无视分片策略，进行全路由，默认 false
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_database_algorithms
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_table_inline

##### 7、INTERVAL #####

时间范围分片算法，针对于时间字段（**字符串类型**）作为分片健的范围分片算法，适用于按照天、月、年这种固定区间的数据分片。 上边使用其它时间分片算法时，用的都是`t_order_n`后缀编号格式的分片表。但业务上往往需要的可能是按月、年`t_order_yyyyMM`的这种分片表格式。

时间范围分片算法（`INTERVAL`），可以轻松实现这种场景，它的属性比较多，逐个解释下：

![图片][0d760349c0a7716565c48e69e1629251.png]

*  datetime-pattern：分片健值的时间格式，必须是Java DateTimeFormatter类支持的转换类型
 *  datetime-lower：分片健值的下界，超过会报错，格式必须与`datetime-pattern`一致
 *  datetime-upper：分片健值的上界，超过会报错，格式必须与`datetime-pattern`一致
 *  sharding-suffix-pattern：分片表后缀名格式，yyyyMM、yyyyMMdd等格式，分片表格式的定义要结合`datetime-interval-unit`的单位，比如：`t_order_yyyyMM`格式表示分片表存的月的数据，`t_order_yyyy`格式表示分片表存的年的数据；
 *  datetime-interval-unit：分片间隔单位，超过该时间间隔将进入下一分片。它遵循 Java ChronoUnit 枚举，比如：`MONTHS`、`DAYS`等；
 *  datetime-interval-amount：分片间隔数，和`datetime-interval-unit`是紧密配合使用；

接下来实现个按月存储数据的场景，用`t_order_202401`～`t_order_202406` 6张分片表存储前半年的数据，每张分片表存储一个月的数据。`interval_value`字段作为分片健，时间字符串类型，允许的分片值时间范围 2024-01-01 00:00:00～2024-06-30 23:59:59 不在范围内插入报错。

spring:
      shardingsphere:
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              t_order_database_mod:
                type: MOD
                props:
                  sharding-count: 2 # 指定分片数量
              t_order_table_interval:
                type: INTERVAL
                props:
                  datetime-pattern: "yyyy-MM-dd HH:mm:ss"  # 分片字段格式
                  datetime-lower: "2024-01-01 00:00:00"  # 范围下限
                  datetime-upper: "2024-06-30 23:59:59"  # 范围上限
                  sharding-suffix-pattern: "yyyyMM"  # 分片名后缀，可以是MM，yyyyMMdd等。
                  datetime-interval-amount: 1  # 分片间隔，这里指一个月
                  datetime-interval-unit: "MONTHS" # 分片间隔单位
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${202401..202406}
                # 分库策略
                database-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_database_mod
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: interval_value
                    sharding-algorithm-name: t_order_table_interval
                keyGenerateStrategy:
                  column: id
                  keyGeneratorName: t_order_snowflake

配置完成后插入测试数据 1月～7月，正常情况下前 6 个月的数据会正常插入，超过界值的 7月数据应该会报错。

// 放入 t_order_202401 分片表
    INSERT INTO `t_order` VALUES (1, 1, '1', 1, 1.00, '2024-01-01 00:00:00', 1);
    // 放入 t_order_202402 分片表
    INSERT INTO `t_order` VALUES (2, 2, '2', 2, 1.00, '2024-02-01 00:00:00', 1);
    // 放入 t_order_202403 分片表
    INSERT INTO `t_order` VALUES (3, 3, '3', 3, 1.00, '2024-03-01 00:00:00', 1);
    // 放入 t_order_202404 分片表
    INSERT INTO `t_order` VALUES (4, 4, '4', 4, 1.00, '2024-04-01 00:00:00', 1);
    // 放入 t_order_202405 分片表
    INSERT INTO `t_order` VALUES (5, 5, '5', 5, 1.00, '2024-05-01 00:00:00', 1);
    // 放入 t_order_202406 分片表
    INSERT INTO `t_order` VALUES (6, 6, '6', 6, 1.00, '2024-06-01 00:00:00', 1);
    
    // 插入会报错
    INSERT INTO `t_order` VALUES (7, 7, '7', 7, 1.00, '2024-07-01 00:00:00', 1);

看到实际的入库的效果和预期的一致，一月的数据存到`t_order_202401`，二月的数据存到`t_order_202402`～，在插入 7月数据的时候报错了。

![图片][bf6d8e7a952b3de421726d588ef42250.png]

#### **COSID 类型算法** ####

ShardingSphere 提供了三种基于散列散列算法的`CosId`（它是一款性能极高分布式ID生成器）分片算法，这个算法的核心思想是通过散列算法对CosId生成的分布式ID和分片键值进行处理，以确定数据应该存放在哪个具体的数据节点上。

使用散列算法的优势，可以将数据按照一定规则映射到不同的数据节点上，能够确保数据的均匀分布，避免某些节点负载过重或者数据倾斜的情况。

三个算法与其他分片算法主要区别在于底层的实现，在配置上使用上基本没太多区别。

##### 8、COSID\_MOD #####

基于 CosId 的取模分片算法和普通的MOD算法使用上略有不同，`mod`为分片数量，`logic-name-prefix`分片数据源或真实表的前缀格式。

![图片][d539dbef523de905d6e1e0f9d351b3ed.png]

`yml`核心配置如下：

spring:
      shardingsphere:
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              t_order_database_mod:
                type: MOD
                props:
                  sharding-count: 2 # 指定分片数量
              # 8、基于 CosId 的取模分片算法
              t_order_table_cosid_mod:
                type: COSID_MOD
                props:
                  mod: 3  # 分片数量
                  logic-name-prefix: t_order_ # 分片数据源或真实表的前缀格式
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_database_mod
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_table_cosid_mod
                keyGenerateStrategy:
                  column: id
                  keyGeneratorName: t_order_snowflake

##### 9、COSID\_INTERVAL #####

基于 CosId 的固定时间范围的分片算法，和`INTERVAL`算法的用法很相似，不同点在于增加了`zone-id`时区属性，`logic-name-prefix`分片数据源或真实表的前缀格式，上下界`datetime-lower`、`datetime-upper`范围的时间格式是固定的`yyyy-MM-dd HH:mm:ss`。

![图片][49b8b0e18cab9fbfcd0389de3ebaa77f.png]

`yml`核心配置如下：

spring:
      shardingsphere:
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              t_order_database_mod:
                type: MOD
                props:
                  sharding-count: 2 # 指定分片数量
              # 基于 CosId 的固定时间范围的分片算法
              t_order_table_cosid_interval:
                type: COSID_INTERVAL
                props:
                  zone-id: "Asia/Shanghai" # 时区，必须遵循 java.time.ZoneId 的所含值。 例如：Asia/Shanghai
                  logic-name-prefix: t_order_ # 分片数据源或真实表的前缀格式
                  sharding-suffix-pattern: "yyyyMM" # 分片数据源或真实表的后缀格式，必须遵循 Java DateTimeFormatter 的格式，必须和 datetime-interval-unit 保持一致。例如：yyyyMM
                  datetime-lower: "2024-01-01 00:00:00" # 时间分片下界值，格式与 yyyy-MM-dd HH:mm:ss 的时间戳格式一致
                  datetime-upper: "2024-12-31 00:00:00" # 时间分片上界值，格式与 yyyy-MM-dd HH:mm:ss 的时间戳格式一致
                  datetime-interval-unit: "MONTHS" # 分片键时间间隔单位，必须遵循 Java ChronoUnit 的枚举值。例如：MONTHS
                  datetime-interval-amount: 1 # 分片键时间间隔，超过该时间间隔将进入下一分片
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${202401..202412}
                # 分库策略
                database-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_database_mod
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: interval_value
                    sharding-algorithm-name: t_order_table_cosid_interval
                keyGenerateStrategy:
                  column: id
                  keyGeneratorName: t_order_snowflake

##### 10、COSID\_INTERVAL\_SNOWFLAKE #####

基于 CosId 的雪花ID固定时间范围的分片算法，和上边的`COSID_INTERVAL`算法不同之处在于，底层用于散列的COSID的生成方式是基于雪花算法（`Snowflake`），内部结合了时间戳、节点标识符和序列号等，这样有助于数据分布更均匀些。

![图片][ebd4dd64089d59796c1572e8384bc9f5.png]

使用除了type类型不同`COSID_INTERVAL_SNOWFLAKE`外，其他属性用法和`COSID_INTERVAL`完全一致。`yml`核心配置如下：

spring:
      shardingsphere:
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              t_order_database_mod:
                type: MOD
                props:
                  sharding-count: 2 # 指定分片数量
              # 基于 CosId 的固定时间范围的分片算法
              t_order_table_cosid_interval_snowflake:
                type: COSID_INTERVAL_SNOWFLAKE
                props:
                  zone-id: "Asia/Shanghai" # 时区，必须遵循 java.time.ZoneId 的所含值。 例如：Asia/Shanghai
                  logic-name-prefix: t_order_ # 分片数据源或真实表的前缀格式
                  sharding-suffix-pattern: "yyyyMM" # 分片数据源或真实表的后缀格式，必须遵循 Java DateTimeFormatter 的格式，必须和 datetime-interval-unit 保持一致。例如：yyyyMM
                  datetime-lower: "2024-01-01 00:00:00" # 时间分片下界值，格式与 yyyy-MM-dd HH:mm:ss 的时间戳格式一致
                  datetime-upper: "2024-12-31 00:00:00" # 时间分片上界值，格式与 yyyy-MM-dd HH:mm:ss 的时间戳格式一致
                  datetime-interval-unit: "MONTHS" # 分片键时间间隔单位，必须遵循 Java ChronoUnit 的枚举值。例如：MONTHS
                  datetime-interval-amount: 1 # 分片键时间间隔，超过该时间间隔将进入下一分片
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${202401..202412}
                # 分库策略
                database-strategy:
                  standard:
                    sharding-column: order_id
                    sharding-algorithm-name: t_order_database_mod
                # 分表策略
                table-strategy:
                  standard:
                    sharding-column: interval_value
                    sharding-algorithm-name: t_order_table_cosid_interval_snowflake
                keyGenerateStrategy:
                  column: id
                  keyGeneratorName: t_order_snowflake

#### **复合分片算法** ####

##### 11、COMPLEX\_INLINE #####

复合行表达式分片算法，适用于多分片健的简单分片场景，和行表达式分片算法使用的方式基本一样。多了一个属性`sharding-columns`分片列名称，多个列用逗号分隔。特别注意：**使用多分片键复合算法，一定要基于复合分片策略进行设置**。

![图片][894df6905f53bdec556c70848b324017.png]

我们对现有的分库分表算法进行了改进，将分片策略修改为`complex`，`sharding-columns`单个分片键升级为多个分片键逗号分隔。例如，将分库表达式从`db$->{order_id % 2}`调整为`db$->{(order_id + user_id) % 2}`，就实现了多个分片键的应用。

`yml`核心的配置如下：

spring:
      shardingsphere:
        # 具体规则配置
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              t_order_database_complex_inline_algorithms:
                type: COMPLEX_INLINE
                props:
                  sharding-columns: order_id, user_id # 分片列名称，多个列用逗号分隔。
                  algorithm-expression: db$->{(order_id + user_id) % 2} # 分片算法的行表达式
                  allow-range-query-with-inline-sharding: false # 是否允许范围查询。注意：范围查询会无视分片策略，进行全路由，默认 false
              # 11、复合行表达式分片算法
              t_order_table_complex_inline:
                type: COMPLEX_INLINE
                props:
                  sharding-columns: order_id, user_id # 分片列名称，多个列用逗号分隔。
                  algorithm-expression: t_order_$->{ (order_id + user_id) % 3 } # 分片算法的行表达式
                  allow-range-query-with-inline-sharding: false # 是否允许范围查询。注意：范围查询会无视分片策略，进行全路由，默认 false
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                  complex:
                    shardingColumns: order_id, user_id
                    sharding-algorithm-name: t_order_database_complex_inline_algorithms
                # 分表策略
                table-strategy:
                  complex:
                    shardingColumns: order_id, user_id
                    sharding-algorithm-name: t_order_table_complex_inline
                keyGenerateStrategy:
                  column: id
                  keyGeneratorName: t_order_snowflake

#### **Hint 分片算法** ####

##### 12、HINT\_INLINE #####

Hint 行表达式分片算法（强制路由分片算法），允许我们指定数据分布的分片库和分表的位置。这个算法只有一个属性`algorithm-expression`，直接利用`Groovy`表达式在其中书写分片逻辑。

如果想要向`db0.t_order_1`分片表中插入一条数据，但我的 Insert SQL 中并没有分片健呀，执意执行插入操作可能就会导致全库表路由，插入的数据就会重复，显然是不能接受的。Hint 算法可以很好的解决此场景。

> HINT\_INLINE **算法一定要在 HINT 分片策略内使用**，否则会报错。

核心的配置如下：其中两个表达式`db$->{Integer.valueOf(value) % 2}`和`t_order_$->{Integer.valueOf(value) % 3}`中的`value`值分别是我们通过 `Hint API` 传入的分库值和分表值。

spring:
      shardingsphere:
        rules:
          sharding:
            # 分片算法定义
            sharding-algorithms:
              # Hint 行表达式分片算法
              t_order_database_hint_inline:
                type: HINT_INLINE
                props:
                  algorithm-expression: db$->{Integer.valueOf(value) % 2} # 分片算法的行表达式，默认值${value}
              t_order_table_hint_inline:
                type: HINT_INLINE
                props:
                  algorithm-expression: t_order_$->{Integer.valueOf(value) % 3} # 分片算法的行表达式，默认值${value}
            tables:
              # 逻辑表名称
              t_order:
                # 数据节点：数据库.分片表
                actual-data-nodes: db$->{0..1}.t_order_${0..2}
                # 分库策略
                database-strategy:
                  hint:
                    sharding-algorithm-name: t_order_database_hint_inline
                # 分表策略
                table-strategy:
                  hint:
                    sharding-algorithm-name: t_order_table_hint_inline
                keyGenerateStrategy:
                  column: id
                  keyGeneratorName: t_order_snowflake

配置完分片算法，如何将`value`值传递进来？通过`HintManager`设置逻辑表的分库`addDatabaseShardingValue`、分表`addTableShardingValue`，强制数据分布到指定位置。

@DisplayName("测试 hint_inline 分片算法插入数据")
    @Test
    public void insertHintInlineTableTest() {
          HintManager hintManager = HintManager.getInstance();
          hintManager.clearShardingValues();
          // 设置逻辑表 t_order 的分库值
          hintManager.addDatabaseShardingValue("t_order", 0);
          // 设置逻辑表 t_order 的分表值
          hintManager.addTableShardingValue("t_order", 1);
          // 1%3 = 1 所以放入 db0.t_order_1 分片表
          jdbcTemplate.execute("INSERT INTO `t_order`(`id`,`order_date`,`order_id`, `order_number`, `customer_id`, `total_amount`, `interval_value`, `user_id`) VALUES (1, '2024-03-20 00:00:00', 1, '1', 1, 1.00, '2024-01-01 00:00:00', 1);");
          hintManager.close();
    }

ShardingSphere 通过使用`ThreadLocal`管理强制路由配置，可以通过编程的方式向`HintManager`中添加分片值，该分片值仅在当前线程内生效。

*  HintManager.getInstance() 获取 HintManager 实例；
 *  HintManager.addDatabaseShardingValue，HintManager.addTableShardingValue 方法设置分片键值；
 *  执行 SQL 语句完成路由和执行；
 *  最后调用 HintManager.close 清理 ThreadLocal 中的内容。

按我们设定的数据节点位置，插入一条测试数据，看到确实存在了`db0.t_order_1`中，完美！

![图片][804c7451e9f9b67949717d540bde374e.png]

### 总结 ###

本文中我们讲解了`ShardingSphere-jdbc`所支持的12种分片算法，每种算法都具有独特的特点。在实际应用中，需要结合具体的业务场景来灵活选择和应用适合的分片算法。

由于篇幅已经够长了，剩下的 3 种自定义分片算法会在下一篇中详细介绍。

[9647b3b0a70d38131c41d77c9d37240a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/2af1ad1f9d8b47f096715086af49ea29.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzAxNTM4NzAyNg==&mid=2247506123&idx=1&sn=50ea1c80fbd145a0407a647cbbb10a10&scene=21#wechat_redirect
[9d4c9196e75ae8e85c1e4747c2687c3c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/2241d2b9f9ef4f9086bbec748bc28226.png
[655498e8a88685497059a88bb0709133.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/8d90ef282ed54d509c265967c876e0cb.png
[8fad2a9a483c6a24d5dc6511fde3eace.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/41de4762e9ac49ea9c12428d17c89e46.png
[22680aaa78b791489d4bf08de0a67044.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/d1ba956db4cc4d41820f819af4b176f9.png
[fce49baf782f4ee67cd1256803875d08.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/ddeba0b1f0eb4899a47185beb8fe5bca.png
[91034dc04acd8c40770dda9bf20412c1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/c7d4eb4f275b422992b6cfa0e888f282.png
[7d9b72acb105d9dce0a3765b37ee50d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/1ebe13980dae44478cd37a5057a30a2b.png
[d7dced7d641cbb01bc9fd7d804442710.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/b8bdf11c32404fefb1b40465ca29fae0.png
[8eae62d497af6bd0ec99c582157d137d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/12683e1d13fc45d8960653ffc90359e2.png
[65a24c99672c5035d669114328a01178.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/9c5cdc8a59f045469498668f8e42d057.png
[066d48523693bdc5ee3fafa52c4f5639.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/14aec2318217407f8e722ccc8d8e7e05.png
[0d760349c0a7716565c48e69e1629251.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/56aceedfcd27410fa8222e7e05f24161.png
[bf6d8e7a952b3de421726d588ef42250.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/773b6f5fb6e94aec834629e7157743b3.png
[d539dbef523de905d6e1e0f9d351b3ed.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/78f3fe6884de45ebbfabf9f8a971c43d.png
[49b8b0e18cab9fbfcd0389de3ebaa77f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/9a2d4d7b3b6a421c801ddf725e5bcebb.png
[ebd4dd64089d59796c1572e8384bc9f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/48156266b9064944a53dcec3ccce04d6.png
[894df6905f53bdec556c70848b324017.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/3120d23d7d524cc78ce992b0f5b6e935.png
[804c7451e9f9b67949717d540bde374e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/859353f2c9494463890678f5ec7ba076.png