在基于Solr的搜索中，我们从使用短语开始。例如，当用户键入
时blue dress
则Solr查询将是
title:"blue dress" OR description:"blue dress"
我们现在要删除停止词。使用默认的StopFilterFactory，查询
the blue dress
将匹配包含"blue dress"或"the blue dress"的文档。
但是，当输入 时，blue the dress
则不匹配包含"blue dress"的文档。
我开始怀疑我们是否应该只使用单个术语进行搜索。即，将上述用户搜索转换为
title:the OR title:blue OR title:dress OR description:the OR description:blue OR description:dress
我有点不愿意这样做，尽管，因为它似乎在做StandardTokenizerFactory的工作。
这是我的schema.xml:
<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
<analyzer type="index">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
<filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="25" />
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.SnowballPorterFilterFactory" language="English" />
</analyzer>
<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
<filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="25" />
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.SnowballPorterFilterFactory" language="English" />
</analyzer>
</fieldType>
标题和描述字段的类型都是text_general。
单项搜索是Solr中标准的搜索方式吗?在调用Solr之前对单词进行标记是否会导致问题(可能是性能问题)?也许单一术语和短语的思维方式是错误的，我们应该让用户自己决定?
您遇到的问题是stopwordfilter阻止对停顿词进行索引，但是它们的位置仍然被索引。类似空格符的东西存储在停词所在的索引中。
所以当你把这个放到索引
蓝色连衣裙
将被索引为
*蓝色连衣裙
当你交上短语
时也会发生同样的情况作为查询。它将被视为
蓝色*礼服
现在Solr将这两个片段进行比较，结果不匹配，因为*在错误的位置。
在Solr 4.4之前，这是通过Pascal Dimassimo描述的在StopFilterFactory中设置enablePositionIncrements="true"来解决的。很明显，在SO和Solr的Jira上讨论的StopFilterFactory的重构确实打破了这个选项。
在阅读Extended Dis Max Query Parser的参考文档时，我发现了这个
stopwords参数一个布尔参数，指示在解析查询时是否应该尊重查询分析器中配置的StopFilterFactory:如果为false，则忽略查询分析器中的StopFilterFactory。
我将检查这是否有助于解决问题。
虽然最初的方法在将查询拆分为多个title:term语句时可能有效，但这很容易出错(因为标记可能在错误的位置被拆分)，并且可能严重地重复了内置标记器所做的工作。
正确的方法是按原样维护初始查询，并依赖Solr配置来正确处理它。这是有意义的，但困难在于我想要指定我想要搜索的字段。事实证明，使用默认的查询解析器是没有办法做到这一点的，这是一个被称为LuceneQParserPlugin(令人困惑的是，有一个名为fl的参数，用于字段列表，它用于指定返回的字段，而不是要搜索的字段)。
为了完成，必须提到，可以通过使用copyField配置来模拟要搜索的参数列表是schema.xml。我觉得这不够优雅，也不够灵活。
优雅的解决方案是使用ExtendedDisMax查询解析器，即edismax。有了它，我们就可以按原样维护查询，并充分利用模式中的配置。在我们的例子中，它看起来像这样:
SolrQuery solrQuery = new SolrQuery();
solrQuery.set("defType", "edismax");
solrQuery.set("q", query); // ie. "blue the dress"
solrQuery.set("qf", "description title");
根据本页:
(e)Dismax通常是面向用户的Solr应用程序的最佳首选查询解析器