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

前言

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

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

全部demo案例 GitHub 地址：Springboot-Notebook/shardingsphere101/shardingsphere-algorithms at master · chengxy-nds/Springboot-Notebook · GitHub

分片策略

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

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

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

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

标准分片策略

标准分片策略（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的介绍 分库分表如何管理不同实例中几万张分片表？。

自动分片算法

1、MOD

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

这个 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_datesharding-algorithm-name: t_order_table_mod# 分片算法定义sharding-algorithms:t_order_table_mod:type: MOD # 取模分片算法props:# 指定分片数量sharding-count: 6tables:t_order: # 逻辑表名称actual-data-nodes: db$->{0..1}.t_order_${0..2}# 分库策略database-strategy:....# 分表策略table-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_table_mod

2、HASH_MOD

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

YML核心配置如下：

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

3、VOLUME_RANGE

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

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

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

VOLUME_RANGE算法主要有三个属性：

看完是不是一脸懵逼，上界下界都是什么含义，我们实际使用一下就清晰了。为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_datesharding-algorithm-name: t_order_table_volume_rangesharding-algorithms:t_order_table_volume_range:type: VOLUME_RANGEprops: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_idsharding-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

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

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

4、BOUNDARY_RANGE

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

比如，我们配置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。

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

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

spring:shardingsphere:rules:sharding:# 自动分片表规则配置auto-tables:t_order:actual-data-sources: db$->{0..1}sharding-strategy:standard:sharding-column: order_datesharding-algorithm-name: t_order_table_boundary_rangesharding-algorithms:# 基于分片边界的范围分片算法t_order_table_boundary_range:type: BOUNDARY_RANGEprops:sharding-ranges: 10,20,30,40 # 分片的范围边界，多个范围边界以逗号分隔tables:t_order: # 逻辑表名称actual-data-nodes: db$->{0..1}.t_order_${0..2}# 分库策略database-strategy:....# 分表策略table-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_table_boundary_range

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

5、AUTO_INTERVAL

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

这里分片健已经从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_datesharding-algorithm-name: t_order_table_auto_interval# 分片算法定义sharding-algorithms:# 自动时间段分片算法t_order_table_auto_interval:type: AUTO_INTERVALprops:datetime-lower: '2023-01-01 00:00:00' # 分片的起始时间范围，时间戳格式：yyyy-MM-dd HH:mm:ssdatetime-upper: '2025-01-01 00:00:00' #  分片的结束时间范围，时间戳格式：yyyy-MM-dd HH:mm:sssharding-seconds: 31536000 # 单一分片所能承载的最大时间，单位：秒，允许分片键的时间戳格式的秒带有时间精度，但秒后的时间精度会被自动抹去tables:# 逻辑表名称t_order:# 数据节点：数据库.分片表actual-data-nodes: db$->{0..1}.t_order_${0..2}# 分库策略database-strategy:standard:sharding-column: order_datesharding-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);

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

标准分片算法

6、INLINE

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

该算法有两属性：

  • 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: INLINEprops:algorithm-expression:	t_order_$->{order_id % 3} # 分片算法的行表达式allow-range-query-with-inline-sharding: false # 是否允许范围查询。注意：范围查询会无视分片策略，进行全路由，默认 falsetables:# 逻辑表名称t_order:# 数据节点：数据库.分片表actual-data-nodes: db$->{0..1}.t_order_${0..2}# 分库策略database-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_database_algorithms# 分表策略table-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_table_inline

7、INTERVAL

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

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

  • 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: MODprops:sharding-count: 2 # 指定分片数量t_order_table_interval:type: INTERVALprops: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_idsharding-algorithm-name: t_order_database_mod# 分表策略table-strategy:standard:sharding-column: interval_valuesharding-algorithm-name: t_order_table_intervalkeyGenerateStrategy:column: idkeyGeneratorName: 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月数据的时候报错了。

COSID 类型算法

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

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

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

8、COSID_MOD

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

yml核心配置如下：

spring:shardingsphere:rules:sharding:# 分片算法定义sharding-algorithms:t_order_database_mod:type: MODprops:sharding-count: 2 # 指定分片数量# 8、基于 CosId 的取模分片算法t_order_table_cosid_mod:type: COSID_MODprops: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_idsharding-algorithm-name: t_order_database_mod# 分表策略table-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_table_cosid_modkeyGenerateStrategy:column: idkeyGeneratorName: t_order_snowflake

9、COSID_INTERVAL

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

yml核心配置如下：

spring:shardingsphere:rules:sharding:# 分片算法定义sharding-algorithms:t_order_database_mod:type: MODprops:sharding-count: 2 # 指定分片数量# 基于 CosId 的固定时间范围的分片算法t_order_table_cosid_interval:type: COSID_INTERVALprops:zone-id: "Asia/Shanghai" # 时区，必须遵循 java.time.ZoneId 的所含值。 例如：Asia/Shanghailogic-name-prefix: t_order_ # 分片数据源或真实表的前缀格式sharding-suffix-pattern: "yyyyMM" # 分片数据源或真实表的后缀格式，必须遵循 Java DateTimeFormatter 的格式，必须和 datetime-interval-unit 保持一致。例如：yyyyMMdatetime-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 的枚举值。例如：MONTHSdatetime-interval-amount: 1 # 分片键时间间隔，超过该时间间隔将进入下一分片tables:# 逻辑表名称t_order:# 数据节点：数据库.分片表actual-data-nodes: db$->{0..1}.t_order_${202401..202412}# 分库策略database-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_database_mod# 分表策略table-strategy:standard:sharding-column: interval_valuesharding-algorithm-name: t_order_table_cosid_intervalkeyGenerateStrategy:column: idkeyGeneratorName: t_order_snowflake

10、COSID_INTERVAL_SNOWFLAKE

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

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

spring:shardingsphere:rules:sharding:# 分片算法定义sharding-algorithms:t_order_database_mod:type: MODprops:sharding-count: 2 # 指定分片数量# 基于 CosId 的固定时间范围的分片算法t_order_table_cosid_interval_snowflake:type: COSID_INTERVAL_SNOWFLAKEprops:zone-id: "Asia/Shanghai" # 时区，必须遵循 java.time.ZoneId 的所含值。 例如：Asia/Shanghailogic-name-prefix: t_order_ # 分片数据源或真实表的前缀格式sharding-suffix-pattern: "yyyyMM" # 分片数据源或真实表的后缀格式，必须遵循 Java DateTimeFormatter 的格式，必须和 datetime-interval-unit 保持一致。例如：yyyyMMdatetime-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 的枚举值。例如：MONTHSdatetime-interval-amount: 1 # 分片键时间间隔，超过该时间间隔将进入下一分片tables:# 逻辑表名称t_order:# 数据节点：数据库.分片表actual-data-nodes: db$->{0..1}.t_order_${202401..202412}# 分库策略database-strategy:standard:sharding-column: order_idsharding-algorithm-name: t_order_database_mod# 分表策略table-strategy:standard:sharding-column: interval_valuesharding-algorithm-name: t_order_table_cosid_interval_snowflakekeyGenerateStrategy:column: idkeyGeneratorName: t_order_snowflake

复合分片算法

11、COMPLEX_INLINE

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

我们对现有的分库分表算法进行了改进，将分片策略修改为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_INLINEprops: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_INLINEprops:sharding-columns: order_id, user_id # 分片列名称，多个列用逗号分隔。algorithm-expression: t_order_$->{ (order_id + user_id) % 3 } # 分片算法的行表达式allow-range-query-with-inline-sharding: false # 是否允许范围查询。注意：范围查询会无视分片策略，进行全路由，默认 falsetables:# 逻辑表名称t_order:# 数据节点：数据库.分片表actual-data-nodes: db$->{0..1}.t_order_${0..2}# 分库策略database-strategy:complex:shardingColumns: order_id, user_idsharding-algorithm-name: t_order_database_complex_inline_algorithms# 分表策略table-strategy:complex:shardingColumns: order_id, user_idsharding-algorithm-name: t_order_table_complex_inlinekeyGenerateStrategy:column: idkeyGeneratorName: 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_INLINEprops:algorithm-expression: db$->{Integer.valueOf(value) % 2} # 分片算法的行表达式，默认值${value}t_order_table_hint_inline:type: HINT_INLINEprops: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_inlinekeyGenerateStrategy:column: idkeyGeneratorName: 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中，完美！

总结

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

文章转载自：程序员小富

原文链接：https://www.cnblogs.com/chengxy-nds/p/18097298

体验地址：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/287887.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

大学教材《C语言程序设计》(浙大版)课后习题解析 | 第三、四章

大学教材《C语言程序设计》(浙大版)课后习题解析 | 第三、四章

概述 本文主要提供《C语言程序设计》(浙大版) 第三、四章的课后习题解析&#xff0c;以方便同学们完成题目后作为参考对照。后续将更新第五、六章节课后习题解析&#xff0c;如想了解更多&#xff0c;请持续关注该专栏。 专栏直达链接&#xff1a;《C语言程序设计》(浙大版)_孟…
阅读更多...
文件IO的方式读取jpeg图片的分辨率

文件IO的方式读取jpeg图片的分辨率

1、读取jpeg图片分辨率的两种方式 1.1 使用libjpeg库 可以使用libjpeg库读取JPEG图像文件&#xff0c;并获取图像的分辨率&#xff08;宽度和高度&#xff09;&#xff0c;简单demo示例如下&#xff1a; #include <stdio.h> #include <jpeglib.h>int main() {st…
阅读更多...
接口测试、postman、测试点提取【主】

接口测试、postman、测试点提取【主】

接口测试是测试系统组件间接口的一种测试 接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点 测试的重点是要检查数据的交换&#xff0c;传递和控制管理过程&#xff0c;以及系统间的相互逻辑依赖关系 文章目录 HTTP接口 & Web Service接口RESTful接口…
阅读更多...
sentinel热点参数流控

sentinel热点参数流控

1、概念 热点参数限流会统计传入参数中的热点参数&#xff0c;并根据配置的限流阈值与模式&#xff0c;对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制&#xff0c;仅对包含热点参数的资源调用生效。 2、示例 2.1、目的 对于如下的/get接口的参…
阅读更多...
what is apache?

what is apache?

Apache 通常指 Apache Software Foundation (ASF) 或 Apache HTTP Server&#xff0c;两者都是计算机软件领域的重要实体。 Apache 软件基金会 (ASF)&#xff1a;Apache 软件基金会是一个开发开源软件项目的非营利组织。它为涵盖软件开发各个方面的广泛项目提供支持&#xff0c…
阅读更多...
Redis 教程系列之Redis PHP 使用 Redis(十二)

Redis 教程系列之Redis PHP 使用 Redis(十二)

PHP 使用 Redis 安装 开始在 PHP 中使用 Redis 前&#xff0c; 我们需要确保已经安装了 redis 服务及 PHP redis 驱动&#xff0c;且你的机器上能正常使用 PHP。 接下来让我们安装 PHP redis 驱动&#xff1a;下载地址为:https://github.com/phpredis/phpredis/releases。 P…
阅读更多...
使用启智OpenI平台体验Open-Sora笔记

使用启智OpenI平台体验Open-Sora笔记

OpenI准备部分 镜像代码仓 创建云脑任务 新建调试任务 镜像选择 如果不想体验整个安装配置过程的话&#xff0c;我准备了一个Open-Sora的环境镜像应该可以直接开箱即用 地址&#xff1a; 192.168.204.22:5000/default-workspace/99280a9940ae44ca8f5892134386fddb/image:Open…
阅读更多...
sql注入五-WEB攻防-注入工具SQLMAPTamper编写指纹修改高权限操作目录架构

sql注入五-WEB攻防-注入工具SQLMAPTamper编写指纹修改高权限操作目录架构

演示案例&#xff1a; 数据猜解-库表列数据&字典权限操作-文件&命令&交互式提交方法-POST&HEAD&JSON绕过模块-Tamper脚本-使用&开发分析拓展-代理&调试&指纹&风险&等级 #参考&#xff1a; https://www.cnblogs.com/bmjoker/p/9326258.…
阅读更多...
PMBOK第八版、项目管理AI标准...PMI标准今年有这些进展

PMBOK第八版、项目管理AI标准...PMI标准今年有这些进展

项目管理实践标准不断在演变&#xff0c;PMI作为项目管理领域的权威机构&#xff0c;一直致力于与全球各行各业的项目实践者一同探索和研究最新的行业标准&#xff0c;确保PMI标准符合全球项目专业人士当前能力建设与职业发展的需要。 今年以来&#xff0c;我们发布了一系列PM…
阅读更多...
NetSuite学习笔记 - 人工成本字段如何按员工所属公司货币显示

NetSuite学习笔记 - 人工成本字段如何按员工所属公司货币显示

在员工档案中输入了人工成本1000&#xff0c;在列表中显示的跟详情中显示的不一样&#xff1f;为什么&#xff1f;怎么办&#xff1f; 详情页中维护人工成本为1000 列表中显示为140.77 1. 开始我以为是因为用的中文环境&#xff0c;可能选了两个不同的字段&#xff0c;切换到英…
阅读更多...
学习笔记：MYSQL数据库基础知识

学习笔记：MYSQL数据库基础知识

MYSQL数据库基础知识学习笔记 MYSQL基础学习数据库相关概念现主流数据库排名数据模型SQL分类SQL数据库基础操作 2024/3/27 学习资料&#xff1a;黑马程序员:MYSQL MYSQL基础学习 数据库和数据库管理系统(DBMS) 数据库: 是存储数据的集合&#xff0c;包括表、视图、索引等对象…
阅读更多...
client-go中ListAndWatch机制，informer源码详解

client-go中ListAndWatch机制，informer源码详解

文章首发地址&#xff1a; 学一下 (suxueit.com)https://suxueit.com/article_detail/s9UMb44BWZdDRfKqFv22 先上一张&#xff0c;不知道是那个大佬画的图 简单描述一下流程 client-go封装部分 以pod为例 、先List所有的Pod资源&#xff0c;然后通过已经获取的pod资源的最大版…
阅读更多...
阿里云 -- 连接云服务器ECS、管理云服务器ECS、WordPress 页面配置

阿里云 -- 连接云服务器ECS、管理云服务器ECS、WordPress 页面配置

连接云服务器ECS 1. 远程连接云服务器ECS&#xff0c;点击实例最右侧操作列的远程连接按钮&#xff0c;并在弹出的对话框中点击立即登录 2. 登录云服务器ECS&#xff0c;通过密码认证方式&#xff0c;输入用户名和密码 提示&#xff1a;新创建的ECS实例状态即使为运行中&#…
阅读更多...
微信投票小程序源码系统：创建新活动+多模板一键切换 带完整的安装代码包以及搭建教程

微信投票小程序源码系统：创建新活动+多模板一键切换 带完整的安装代码包以及搭建教程

随着社交媒体的普及&#xff0c;投票活动已经成为人们表达意见、参与决策的重要方式。微信小程序作为一种新兴的应用形态&#xff0c;具有用户基数大、使用门槛低的特点&#xff0c;非常适合举办投票活动。然而&#xff0c;对于普通用户来说&#xff0c;开发一个功能完善的投票…
阅读更多...
xilinx的高速接口构成原理和连接结构

xilinx的高速接口构成原理和连接结构

本文来源&#xff1a; V3学院 尤老师的培训班笔记【高速收发器】xilinx高速收发器学习记录Xilinx-7Series-FPGA高速收发器使用学习—概述与参考时钟GT Transceiver的总体架构梳理 文章目录 一、概述&#xff1a;二、高速收发器结构&#xff1a;2.1 QUAD2.1.1 时钟2.1.2 CHANNEL…
阅读更多...
前端html常用标签 笔记

前端html常用标签 笔记

一、基础 开始标签 结束标签 大部分是成对出现的标签&#xff0c;这个是空标签(/放在最后&#xff0c;/可以省掉) 缩进 向后Tab 、前向ShiftTab 红的就是元素属性 标签可以使内容有一些特殊的表现: 给body颜色后&#xff1a; h1 span(连起来) 标签&#xff1a; 标题h1 h2 h3 …
阅读更多...
介绍部署esxi8.0产品的方式

介绍部署esxi8.0产品的方式

什么是esxi esxi的中文叫裸机虚拟机管理器 ESXi是由VMware公司开发的一种裸机虚拟机管理器&#xff0c;全称为VMware ESXi。 ESXi是一种虚拟化技术&#xff0c;专门设计用于在物理服务器上运行虚拟机&#xff0c;它的主要特点是能够最大限度地降低硬件配置要求并简化部署过程…
阅读更多...
Android 性能优化实例分享-内存优化 兼顾效率与性能

Android 性能优化实例分享-内存优化 兼顾效率与性能

背景 项目上线一段时间后,回顾重要页面 保证更好用户体验及生产效率&#xff0c;做了内存优化和下载导出优化&#xff0c;具体效果如最后的一节的表格所示。 下面针对拍摄流程的两个页面 预览页 导出页优化实例进行介绍&#xff1a; 一.拍摄前预览页面优化 预览效果问题 存在…
阅读更多...
tcp 协议详解

tcp 协议详解

什么是 TCP 协议 TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制。TCP 是一个传输层的协议。 如下图&#xff1a; 我们接下来在讲解 TCP/IP 协议栈的下三层时都会先解决这两个问题&#xff1a; 报头与有效载荷如何…
阅读更多...
EtherCAT转RS232网关在风电领域的应用

EtherCAT转RS232网关在风电领域的应用

开疆智能EtherCAT转RS232网关在风电领域的应用主要体现在以下几个方面&#xff1a; 1.数据采集与传输&#xff1a;在风力发电设备中&#xff0c;传感器和执行器的数据采集和传输至关重要。EtherCAT转RS232网关可以将风力发电设备中的RS232通信协议转换为EtherCAT协议&#xff0…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023