许多我们帮助过的客户希望他们的搜索比仅仅将查询与文档严格匹配更智能， 将搜索集成到他们的应用程序中 。
有很多方法可以做到这一点。Manticore Search 使这变得非常简单，因为模糊匹配是开箱即用的。它由三个主要组件组成：

1. 多数运算符：

"computing and technology news"/2这意味着短语中的至少两个词应该匹配，即此查询将找到包含“计算新闻”和“技术新闻”的文本。

2. 接近搜索运算符：

"computing news"~3这意味着在查询中的单词之间可以有少于 N 个不匹配的单词。以下是一些示例，给定文本为 a b c d e f g h：

• "a h"~7会发现，因为 b c d e f h 是 6 个不匹配的单词，而这少于 7
  然而 "a h"~6 不会找到文本
• "a d h"~6 会找到
• "a d h"~5 不会

3. NEAR 运算符

computing NEAR/6 "technology news"

上述 接近 运算符仅适用于关键词集合。NEAR 更为通用，可以接受任意子表达式作为其两个参数，当两个子表达式在 N 个单词内找到时，匹配文档，无论顺序如何。

上述查询将：

• 与包含 computing is a popular topic in technology news 的文档匹配，因为第一个单词和短语在 6 个单词内找到
• 但不会与 computing nowadays is a popular topic in* technology news 匹配，因为间隔已经是 6，超过了 NEAR 运算符设置的限制。

第二次查询逻辑

我们的许多客户使用第二次查询逻辑：这意味着您首先运行一个更严格的查询，然后如果没有找到任何结果或返回的结果不够，则发出第二个不那么严格的查询。也可能有更高级的逻辑，涉及第三次和第四次查询。这取决于您的要求，以及您是否希望用户在任何情况下至少找到一些内容。或者，反之，您可以让他们找到与其查询完全匹配的内容。

有时反过来做并使查询更严格是有意义的。例如，如果您的默认匹配策略是“任何单词都应该匹配”，而您的应用程序没有任何扩展语法来允许用户自己指定最佳查询，那么首先尝试“所有单词都应该匹配”策略或甚至“短语应该匹配”是有意义的。这可能显著提高搜索的质量。

在某些应用程序中，将第一次/第二次查询并行化是有意义的，依此类推。这可以通过 Manticore Search 的多查询轻松实现。这里的逻辑是提前进行第二次查询，如果第一次查询没有找到任何内容，结果将准备好，并且由于查询是同时进行的，这提高了性能。然而，这取决于很多因素。您应该小心，因为有时这可能会降低性能。这些因素包括：

• 您使用的硬件是什么？如果它的性能不足以同时处理两个查询，或者响应时间接近于单个查询的响应时间的两倍，那么使用这种技术就没有太大意义。
• 您的负载是什么？如果您的 Manticore Search 实例/服务器已经负载很重，您将获得更差的响应时间。
• 您的统计数据是什么？如果在 99% 的查询中，第一次查询返回结果，那么与第一次查询一起进行第二次查询就没有太大意义，这只会浪费资源。