Solr 为什么不建议使用通配符搜索实现typeahead？

通常，大多数教程都建议使用Suggester组件或原始字体技术实现autosuggest：

然而，我的问题是，为什么没有人建议使用简单的通配符搜索，比如在用户键入mob时给出姓名建议：

q=name:(*mob*)

---

与其他方法相比，使用这种方法实现autosuggest是否可行？会产生什么影响？

对于简单的查询，该策略可以起作用。问题是，当您使用通配符进行查询时，分析链不会被调用（有点简化-大多数过滤器不会被调用，只有那些是MultiTermAware的过滤器才会被调用）-因此，只要您键入一个空格，您就倒霉了。您可以使用ComplexPhraseQuery来解决这个问题，但这可能不是您想要的（而且术语的数量可能会很快变得昂贵）

在您使用前导通配符的示例中，查询也会非常昂贵，因为它需要Lucene（Solr的底层搜索库）查看每个生成的令牌，并查看该令牌中是否有文本

mob

。而且，由于您没有进行任何分析-如果您将

男士的

编入索引（在大多数情况下，这将被处理为只匹配

男士

，作为单个标记），并搜索

男士的*

，您就不会得到成功

---

所以它是有效的——有点——但并不理想。这就是为什么建议被实施的原因。获取您想要的行为，以及（对于某些后端）上下文过滤（仅使用通配符更容易实现，因为它是常规的

fq

）。suggester还支持权重-而通配符并不能真正做到这一点。

非常感谢您的回复。但是我尝试用反冲空格替换空格，似乎对大多数人都有效。这取决于对输入文本进行了何种分析以生成标记。