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

1. 多数算子：

"computing and technology news"/2 这意味着短语中的至少两个词需要匹配，即此查询会找到同时包含“computing news”和“technology news”的文本。

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% 的查询在第一次查询时就返回了结果，那么与第一次查询一起执行第二次查询就没有多大意义，这只会浪费资源。