TiKV中GBK/GB18030字符集分组查询的编码问题分析

问题背景

在TiKV数据库系统中，当用户使用GBK或GB18030字符集创建表并执行包含GROUP BY子句的查询时，可能会遇到"encoding failed"错误。这个问题主要出现在TiKV 6.5及更高版本中，影响了大量使用中文环境的用户。

问题现象

用户创建了一个使用GBK字符集的表，并尝试执行包含GROUP BY和COLLATE子句的查询时，系统返回错误信息"(1105, 'encoding failed')"。具体表现为：

1. 创建包含GBK字符集的表
2. 插入包含多字节GBK编码的中文字符
3. 执行带有GROUP BY和COLLATE子句的查询时失败

技术分析

根本原因

问题的根源在于TiKV处理GBK字符集时的长度计算逻辑存在缺陷。在TiKV的代码实现中，当处理VARCHAR(4)这样的字段定义时，系统错误地将"4"解释为字节数而非字符数。

对于GBK编码，每个中文字符占用2个字节。当字段定义为VARCHAR(4)时，实际应该允许存储最多4个中文字符(8字节)，但系统错误地将其限制为4字节，导致无法正确存储和查询包含多个中文字符的数据。

版本影响分析

这个问题在不同版本的TiKV中表现不同：

1. 5.4和6.1版本：由于Hash Aggregation操作未下推到TiKV执行，问题不会出现
2. 6.5、7.1、7.5及更高版本：由于优化器将Hash Aggregation下推到TiKV执行，问题显现

执行计划分析

在受影响版本中，查询执行计划显示HashAgg操作被下推到TiKV协处理器执行。在协处理器处理GBK编码数据时，由于长度计算错误，导致编码转换失败。

解决方案建议

要解决这个问题，需要在TiKV中修正字符集处理的逻辑：

1. 对于GBK/GB18030字符集，正确区分字符长度和字节长度
2. 在编码转换时，考虑多字节字符的完整性问题
3. 对于VARCHAR(n)定义，应根据字符集特性正确计算最大允许字节数

总结

这个问题凸显了数据库系统在处理多字节字符集时需要特别注意的编码细节。对于中文用户来说，GBK/GB18030字符集的支持至关重要。TiKV开发团队需要确保在优化查询执行路径时，不会破坏字符集处理的基本逻辑，特别是在将操作下推到存储层执行时。