GreatSQL数据库连接字段长度对Hash Join性能的影响研究

一、现象观察

在数据库开发实践中，我们发现当使用VARCHAR类型字段作为Hash Join连接条件时，字段长度的差异会导致执行计划产生显著变化。以下通过三个典型场景进行说明。
1. 短字段连接场景（20字符）

greatsql> CREATE TABLE t1 (c1 INT, c2 varchar(20)) CHARSET=utf8mb4;
greatsql> CREATE TABLE t3 (ccc1 INT, ccc2 varchar(20)) CHARSET=utf8mb4;

执行计划显示直接使用Hash Join：

greatsql> EXPLAIN format=tree SELECT * FROM t1 JOIN t3 ON t1.c2=t3.ccc2;

1. 长字段连接场景（1000字符）

greatsql> CREATE TABLE t1 (c1 INT, c2 varchar(1000)) CHARSET=utf8mb4;
greatsql> CREATE TABLE t3 (ccc1 INT, ccc2 varchar(1000)) CHARSET=utf8mb4;

执行计划显示额外增加了过滤层：

greatsql> EXPLAIN format=tree SELECT * FROM t1 JOIN t3 ON t1.c2=t3.ccc2;

1. BLOB类型连接场景

greatsql> CREATE TABLE t11 (c1 INT, c2 blob) CHARSET=utf8mb4;
greatsql> CREATE TABLE t13 (ccc1 INT, ccc2 blob) CHARSET=utf8mb4;

执行计划同样显示需要额外过滤处理。

二、技术原理探究

通过分析GreatSQL源码，发现优化器在生成执行计划时会对连接字段长度进行判断。关键代码逻辑如下：

if (cs->coll->strnxfrmlen(cs, cs->mbmaxlen * m_max_character_length) > 1024) {
m_store_full_sort_key = false;
}

当计算出的内部表示长度超过1024字节时，系统会采用哈希值替代完整键值存储，从而需要后续的二次过滤验证。

三、长度计算机制

不同字符集的计算公式存在差异：
字符集类型 | 计算公式 | 说明
—|—|—
utf8mb4 | ((len + 3)/4)2 | 基于4字节最大长度
utf8mb3 | ((len + 2)/3)2 | 基于3字节最大长度
示例计算：
对于utf8mb4字符集的varchar(300)字段：
最终计算结果4800 > 1024，因此需要额外过滤层。

四、优化建议

基于研究发现，提出以下优化建议：
1. 控制连接字段长度，utf8mb4字符集建议不超过64字符
2. 避免使用BLOB等大对象类型作为连接条件
3. 合理选择字符集类型

GreatSQL数据库作为金融级开源解决方案，在保持高性能的同时提供了完善的安全保障机制。欢迎加入技术社区交流讨论。
技术交流：

扫描下方二维码添加社区助手加入技术交流群
[社区图片保留]