【笔记】开发指南—函数—拆分函数—STR_HASH

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 本文将介绍STR_HASH函数使用方式

描述

STR_HASH函数通过指定字符串的开始位置下标与结束下标,以截取拆分键的字符串的某段子串,然后将其作为字符串(或整数)输入进行分库分表的路由计算具体的物理分片,函数如下所示:


STR_HASH( shardKey [, startIndex, endIndex [, valType [, randSeed ] ] ] )
参数 说明
shardKey 拆分键列的列名。
startIndex 目标子串的开始位置的下标。取值从0开始(即原字符串的第1个字符的下标用0表示),默认值为-1(即不做任何截取)。
endIndex 目标子串的结束位置的下标。取值从0开始(即原字符串的第1个字符的下标用0表示),默认值为-1(即不做任何截取)。

startIndex和endIndex时需注意如下几种取值情况:

  • 当startIndex == j && endIndex = k (j>=0, k>=0 ,k>j)时,表示截取原字符串的[ j, k )区间的字符串作为子串。例如:
    • 对于字符串ABCDEFG,子串区间[1,5)的值是BCDE。
    • 对于字符串ABCDEFG,,子串区间[2,2)的值是''。
    • 对于字符串ABCDEFG,子串区间[4,100)的值是EFG。
    • 对于字符串 ABCDEFG,子串区间[100,105)的值是''。
  • 当startIndex == -1 && endIndex = k (k>=0)时,表示截取原字符串最后k个字符作为子串,原字符串不足k个字符则直接获取整个字符串。
  • 当startIndex = k && endIndex == -1 (k>=0)时,表示截取原字符串开头k个字符作为子串,原字符串不足k个字符则直接获取整个字符串。
  • 当startIndex == -1 && endIndex == -1时, 表示不做任何截取,子串与原字符串完全一致。
valType 表示截取后的子串在计算分库分表时所使用的类型,取值范围如下:
  • 0(默认值):表示PolarDB-X将截取后的子串当作字符串类型来计算路由。
  • 1:表示PolarDB-X将截取后的子串当作整数类型来计算路由(子串面值的整数不能大于9223372036854775807,也不支持浮点数)
randSeed 当子串以字符串类型来计算路由的哈希值时PolarDB-X所使用的随机种子的值,通常不用需要填写,仅当用于使用默认值随机种子(randSeed=31)的STR_HASH在实际业务中出现路由不均衡的场景,达到用哈希均衡数据的目的。该参数默认值为31,可取其他值(如131,13131,1313131等)。

说明

  • 仅当valType取值为0时,才支持配置该参数。
  • 该参数调整后您需要手动将所有数据导出来,再将新的拆分算法导入数据(即您需要对数据进行重分布)。

注意事项

使用STR_HASH做拆分的表仅适用于点查场景,如果在业务中范围查询,则会接直接触发全表扫描导致慢查询。

使用限制

  • 拆分键的数据类型需为字符串类型(CHAR或VARCHAR)。
  • 不支持在建表完成后再调整STR_HASH的参数。

使用场景

  • 实现一个分表(或分库)只对应一个拆分表键的取值(字符串类型)的精准路由效果。例如,某个互联网金融应用是按年月(YYYYMM)分库,然后按订单号分表,该应用的订单号有个特点,就是订单号的最后3位字符串是一个整数,其取值范围是000~999。该应用的需求是需要在一个物理分库内,要将订单号后3位的每一个数值只单独路由到一个物理分表。那么,该应用分库采用YYYYMM,然后分表采用拆分函数STR_HASH,每个库1024个分表,就可以达到效果。具体的SQL语句如下:
create table test_str_hash_tb (

id int NOT NULL AUTO_INCREMENT,
order_id varchar(30) NOT NULL,
create_time datetime DEFAULT NULL,
primary key(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
dbpartition by YYYYMM(`create_time`)
tbpartition by STR_HASH(`order_id`, -1, 3, 1) tbpartitions 1024;
  • 应用采用这样建表SQL,原因是分表的字符串截取后3位并转换为整数(整数范围是000~999)后再取模做分表路由(共1024个分表),其路由结果能保证每一个物理分表只对一个拆分建的取值。而原来PolarDB-X默认拆分函数HASH无法达到这样的效果,是因为字符串经过hashCode计算后的整数是不可预知的,有可能会出现一个物理分表要对应多个不同拆分建的取值。
  • STR_HASH拆分函数适用于使用字符串类型作为拆分键并且是绝大部分都是点查的场景,如根据ID查交易订单、物流订单等。

使用示例

假设order_id的类型为VARCHAR(32),现在需要将order_id作为拆分键,计划分4个库,分8个表。

  • 假设需要使用order_id的最后4位的字符串作为整数来计算分库分表路由,则您可以使用如下SQL进行建表。
create table test_str_hash_tb (    
id int NOT NULL AUTO_INCREMENT,
order_id varchar(32) NOT NULL,
create_time datetime DEFAULT NULL,
primary key(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
dbpartition by STR_HASH(`order_id`, -1, 4, 1)
tbpartition by STR_HASH(`order_id`, -1, 4, 1) tbpartitions 2;
  • 假设需要截取order_id的第3个字符(即starIndex=2)与第7个字符(即endIndex=7)之间子串来计算分库分表路由,则您可以使用如SQL进行建表。
create table test_str_hash_tb (    
id int NOT NULL AUTO_INCREMENT,
order_id varchar(32) NOT NULL,
create_time datetime DEFAULT NULL,
primary key(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
dbpartition by STR_HASH(`order_id`, 2, 7)
tbpartition by STR_HASH(`order_id`, 2, 7) tbpartitions 2;
  • 假设需要截取order_id的前5个字符串作为子串来计算分库分表路由,则您可以使用如SQL进行建表。
create table test_str_hash_tb (    
id int NOT NULL AUTO_INCREMENT,
order_id varchar(32) NOT NULL,
create_time datetime DEFAULT NULL,
primary key(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
dbpartition by STR_HASH(`order_id`, 5, -1)
tbpartition by STR_HASH(`order_id`, 5, -1) tbpartitions 2;

常见问题

Q:dbpartition by STR_HASH(order\_id) dbpartition by HASH(order\_id)有什么区别?

A:两者虽然都是直接根据字符串取值做分库分表的哈希路由,但是两者的分库分表的路由算法实现不一样。前者支持用户建表时自行设定截取子串相关参数,且在根据字符串的哈希值计算分库分表路由时是基于UNI_HASH算法进行计算;而后者是只对字符串的哈希值做简单取模。

上一篇:HASH


相关文章
|
5天前
|
数据采集 人工智能 自然语言处理
3分钟采集134篇AI文章!深度解析如何通过云无影AgentBay实现25倍并发 + LlamaIndex智能推荐
结合阿里云无影 AgentBay 云端并发采集与 LlamaIndex 智能分析,3分钟高效抓取134篇 AI Agent 文章,实现 AI 推荐、智能问答与知识沉淀,打造从数据获取到价值提炼的完整闭环。
390 93
|
6天前
|
域名解析 人工智能
【实操攻略】手把手教学,免费领取.CN域名
即日起至2025年12月31日,购买万小智AI建站或云·企业官网,每单可免费领1个.CN域名首年!跟我了解领取攻略吧~
|
5天前
|
SQL 人工智能 自然语言处理
Geo优化SOP标准化:于磊老师的“人性化Geo”体系如何助力企业获客提效46%
随着生成式AI的普及,Geo优化(Generative Engine Optimization)已成为企业获客的新战场。然而,缺乏标准化流程(Geo优化sop)导致优化效果参差不齐。本文将深入探讨Geo专家于磊老师提出的“人性化Geo”优化体系,并展示Geo优化sop标准化如何帮助企业实现获客效率提升46%的惊人效果,为企业在AI时代构建稳定的流量护城河。
394 156
Geo优化SOP标准化:于磊老师的“人性化Geo”体系如何助力企业获客提效46%
|
5天前
|
数据采集 缓存 数据可视化
Android 无侵入式数据采集:从手动埋点到字节码插桩的演进之路
本文深入探讨Android无侵入式埋点技术,通过AOP与字节码插桩(如ASM)实现数据采集自动化,彻底解耦业务代码与埋点逻辑。涵盖页面浏览、点击事件自动追踪及注解驱动的半自动化方案,提升数据质量与研发效率,助力团队迈向高效、稳定的智能化埋点体系。(238字)
278 158
|
13天前
|
机器人 API 调度
基于 DMS Dify+Notebook+Airflow 实现 Agent 的一站式开发
本文提出“DMS Dify + Notebook + Airflow”三位一体架构,解决 Dify 在代码执行与定时调度上的局限。通过 Notebook 扩展 Python 环境,Airflow实现任务调度,构建可扩展、可运维的企业级智能 Agent 系统,提升大模型应用的工程化能力。