ByConity项目中字符串匹配过滤器的逻辑缺陷分析与修复

在分布式数据库系统ByConity的查询处理模块中，ChineseTokenExtractor组件负责处理中文字符串的提取和过滤操作。该组件包含一个关键方法stringLikeToGinFilter，用于将SQL中的LIKE模式匹配条件转换为GIN索引可用的过滤条件。

问题背景

在字符串模式匹配的语义中，LIKE操作符的通配符'%'表示任意长度的字符序列（包括空序列）。当'%'出现在模式字符串的末尾时，表示"以某字符串开头"的匹配逻辑。例如：

• LIKE 'abc%' 匹配所有以"abc"开头的字符串
• LIKE '%abc' 匹配所有以"abc"结尾的字符串
• LIKE '%abc%' 匹配所有包含"abc"子串的字符串

缺陷分析

在ByConity的原始实现中，stringLikeToGinFilter方法对尾部'%'的处理存在逻辑错误。当模式字符串以'%'结尾时，代码错误地将其转换为starts_with过滤条件，而实际上应该使用ends_with过滤条件。这种实现会导致以下问题：

1. 语义不一致：生成的过滤条件与SQL的LIKE语义不符
2. 查询结果错误：可能导致返回不符合条件的数据或遗漏符合条件的数据
3. 性能影响：错误的过滤条件可能导致索引使用效率低下

技术影响

这种底层字符串处理逻辑的错误会对系统产生多方面影响：

1. 查询准确性：对于依赖尾部通配符的查询（如后缀匹配），会返回错误结果集
2. 索引效率：GIN索引无法被正确利用，可能导致全表扫描
3. 中文处理：特别影响中文字符串的模糊查询功能

解决方案

修复方案的核心是将尾部'%'的处理逻辑从starts_with改为ends_with。具体实现需要考虑：

1. 模式字符串解析：正确识别通配符位置
2. 条件转换：根据通配符位置生成对应的过滤条件
3. 边界情况：处理纯通配符、混合通配符等特殊情况

经验总结

这个案例提醒我们在实现字符串匹配功能时需要注意：

1. 严格遵循SQL标准语义
2. 通配符位置的不同会产生完全不同的匹配逻辑
3. 索引转换时需要保持原始查询的语义一致性
4. 特别关注非ASCII字符集（如中文）的处理

对于数据库系统开发者而言，字符串匹配是基础但关键的功能，需要精心设计和充分测试以确保正确性和性能。