Manticore Search中SQL与JSON查询对分隔符处理差异的深度解析

问题背景

在Manticore Search这一高性能全文搜索引擎中，开发人员发现了一个有趣的现象：当使用特定分隔符"甜"进行搜索时，SQL接口和JSON接口返回的结果存在不一致。具体表现为：通过SQL查询match('甜')无法找到包含"abc"的文档，而通过JSON接口的{"match": {"*": "甜"}}查询却能返回该文档。

技术原理分析

经过深入排查，发现这个问题源于查询执行路径的选择机制差异：

1. SQL查询路径：当构建匹配树(Matching Tree)为空时，SQL接口仍然坚持走全文检索路径，导致无法匹配任何文档
2. JSON查询路径：在同样情况下，JSON接口会自动切换到全表扫描(Full-Scan)路径，因此能够返回所有文档

这种差异本质上反映了两种接口在查询优化策略上的不同处理逻辑。SQL接口严格遵循全文检索语义，而JSON接口则更倾向于保证查询总能返回结果。

解决方案实现

开发团队通过以下方式解决了这个问题：

1. 统一执行路径：确保当使用where match语法(SQL)或任何全文检索节点(JSON)时，系统始终保持在全文检索路径上
2. 空匹配树处理：允许查询在匹配树为空的情况下继续执行，只是返回空的文档列表
3. 回归测试保障：新增测试用例(234)并完善现有测试(19,164)，确保各种边界情况都被覆盖

技术影响与启示

这个修复不仅解决了特定查询场景下的结果不一致问题，更重要的是确立了以下原则：

1. 接口行为一致性：不同查询接口应该保持相同的语义和行为
2. 空结果集处理：明确区分"没有匹配"和"匹配条件为空"两种场景
3. 查询路径选择：全文检索查询应该始终优先使用全文索引，即使条件可能匹配不到任何文档

对于开发者而言，这个案例提醒我们：在实现多协议支持的搜索系统时，需要特别注意不同接口间的行为一致性，特别是在边界条件的处理上。同时，完善的测试用例是保证系统稳定性的重要手段。

最佳实践建议

基于此问题的解决经验，我们建议：

1. 在设计跨协议查询系统时，建立统一的查询执行框架
2. 对空查询条件等边界情况制定明确的处理规范
3. 为各种查询场景建立交叉验证测试
4. 文档中明确说明不同查询方式的行为差异(如果有)

这一问题的解决显著提升了Manticore Search在复杂查询场景下的稳定性和可靠性，为后续功能开发奠定了更坚实的基础。