Solr大小写敏感搜索：双字段下分析匹配但查询无结果问题

已知配置与现象说明 #

当前环境的基础配置：

• 文档存储包含两个字段值：多值字段ad_code存储内容为["fsCy"]，单值字段ad_code_string存储内容为"fsCy"
• 字段schema定义：
  • ad_code_string：字段类型为内置string，配置为indexed="true" stored="true"
  • ad_code：字段类型为内置text_general
• 异常现象：通过Solr内置分词分析工具校验时，查询词与文档存储内容可显示匹配，但实际执行查询时无法返回目标文档。

核心异常原因定位 #

1. 分词分析工具的测试逻辑与实际查询链路脱节 #

内置text_general字段类型的默认分析链路自带LowerCaseFilterFactory，会在索引写入、查询处理两个阶段，把所有字符强制转换为全小写，原本的大小写特征会在索引构建阶段被完全抹平。
分析工具的默认匹配校验逻辑，是比对「索引端处理后的token」和「查询端处理后的token」：以测试值fsCy为例，索引端会把原始值转换为fscy存为token，查询端会把输入的fsCy同样转换为fscy做比对，界面自然显示匹配成功。但这个匹配结果和你要实现的“大小写敏感搜索”的目标完全错位——如果你在实际查询时，因为自定义配置、特殊查询语法绕过了查询端的LowerCaseFilter，就会出现原始查询字符串和索引存储的全小写token完全不匹配的情况，最终导致查无结果。很多排查时被界面显示的“匹配成功”结果误导，恰恰是因为这个默认加载全链路过滤的测试逻辑，和实际查询的自定义配置经常存在偏差。

2. 字段选型与查询目标错配 #

ad_code_string采用内置string类型，本身是Solr中最适合做大小写敏感精确匹配的字段：该类型无分词、无字符过滤，会把写入的完整字符串作为单个原封不动的token存储，天然支持大小写区分。
最常见的配置失效场景包括：

• 实际查询时始终在检索ad_code字段，而非专门用于大小写敏感匹配的ad_code_string字段。比如Solr配置了默认查询字段df=ad_code，输入查询词后全部走了text_general的全小写转换链路，和预期的敏感匹配逻辑不匹配。
• schema变更后未执行全量索引重建。如果是在已有文档写入完成后才新增的ad_code_string字段，旧文档的该字段不会自动生成索引值，哪怕管理界面能看到存储的字段值，实际检索也会因为没有对应索引token而无法召回。

3. 查询语法逻辑错位 #

• 针对ad_code_string字段查询时，错误使用通配符、模糊匹配语法，而非精确匹配，导致与原封不动存储的完整token无法对齐。
• 自定义字段类型时，误将LowerCaseFilterFactory、ASCIIFoldingFilterFactory这类会修改原始字符格式的过滤器加入分析链路，哪怕是基于string类型改造的字段，一旦加入大小写转换逻辑，就会完全丢失大小写区分能力。

可落地的验证步骤 #

• 在Schema管理页确认ad_code_string对应的字段类型分析链路，确保链路中不存在任何会修改字符大小写、格式的过滤器，保留原始写入内容的完整特征。
• 清空测试环境已有索引，重新导入测试文档，使用fq=ad_code_string:fsCy的过滤查询语法做验证。过滤查询会完整走字段的默认分析链路，如果可正常召回目标文档，即可确认异常来自主查询的字段配置错误。
• 检查实际查询请求的参数配置，确认默认查询字段、指定检索字段的逻辑，避免把大小写敏感的关键词全部路由到ad_code的全小写分析链路中。

内容的提问来源于stack exchange，提问作者sarin Wickramasinghe