TiKV 中处理 GBK/GB18030 编码字符串时出现 encoding failed 错误分析

问题背景

在 TiKV 分布式数据库系统中，当处理包含 GBK 或 GB18030 编码的字符串查询时，特定情况下会出现 encoding failed 错误。这个问题主要出现在使用 GROUP BY 子句结合 COLLATE 排序规则对 GBK 编码字段进行分组查询的场景中。

问题重现

该问题可以通过以下步骤重现：

1. 创建包含 GBK 编码字段的表
2. 插入包含多字节字符的数据
3. 执行带有 COLLATE 子句的 GROUP BY 查询

具体 SQL 示例如下：

CREATE TABLE t1 (c VARCHAR(4) CHARACTER SET gbk);
INSERT INTO t1 VALUES (0x8BF5819AEDC3); -- 插入'嬽仛砻'等GBK字符
SELECT ANY_VALUE(HEX(c)), COUNT(c) FROM t1 GROUP BY c COLLATE gbk_chinese_ci;

问题本质

问题的根本原因在于 TiKV 对 VARCHAR 类型长度的处理方式。在 TiKV 内部实现中，VARCHAR(4) 的"4"被错误地解释为4个字节而非4个字符。对于单字节编码如 Latin1 这不是问题，但对于多字节编码如 GBK 和 GB18030 就会导致字符串被错误截断。

GBK 编码中，每个中文字符占用2个字节，而 GB18030 则更为复杂，部分字符可能占用4个字节。当系统错误地将长度限制应用于字节而非字符时，就可能截断多字节字符的中间部分，导致无效的编码序列，最终引发 encoding failed 错误。

影响范围

该问题影响以下 TiKV 版本：

• 6.5.x 系列
• 7.1.x 系列
• 7.5.x 系列
• 8.1.x 系列
• 8.5.x 系列

在较早版本如 5.4 和 6.1 中，由于 Hash Aggregation 操作没有下推到 TiKV 执行，因此不会出现此问题。

解决方案建议

要解决这个问题，需要在 TiKV 的编码处理层面对 VARCHAR 类型的长度限制进行修正：

1. 对于多字节字符集，应将长度限制解释为字符数而非字节数
2. 在字符集转换和排序规则处理时，需要完整保留字符的字节序列
3. 对于 GROUP BY 下推操作，确保正确处理多字节字符的完整编码

临时规避方案

对于受影响的用户，可以采取以下临时解决方案：

1. 避免在 TiKV 端执行包含 GBK/GB18030 字段的 GROUP BY 下推操作
2. 增大字段定义的长度，如使用 VARCHAR(8) 替代 VARCHAR(4)
3. 在应用层进行必要的分组计算

总结

TiKV 在处理多字节字符集时的这一行为差异，揭示了分布式数据库系统中字符集处理的重要性。特别是在下推计算到存储层时，需要确保字符集相关操作的一致性。该问题的修复将提高 TiKV 对中文及其他多字节字符集的支持完善度，为使用 GBK/GB18030 编码的用户提供更好的体验。