拼写纠正，也称为：

• 自动纠正
• 文本纠正
• 修正拼写错误
• 容错拼写
• “你的意思是？”

等等，是一种软件功能，用于建议替代词或自动纠正您输入的文本。纠正输入文本的概念可以追溯到20世纪60年代，当时计算机科学家Warren Teitelman（他还发明了“撤销”命令）提出了一种称为D.W.I.M.（“做我意思的事”）的计算哲学。Teitelman认为，计算机不应只接受格式完全正确的指令，而应被编程为识别明显的错误。

第一个提供拼写纠正功能的知名产品是1993年发布的Microsoft Word 6.0。

拼写纠正可以通过几种方式实现，但重要的是要注意，没有纯粹的程序化方法能以较高质量将您错误输入的“ipone”转换为“iphone”。大多数情况下，系统必须基于某个数据集。该数据集可以是：

• 一个正确拼写单词的词典，词典又可以是：
  • 基于您的真实数据。这里的想法是，词典中由您的数据组成的拼写大部分是正确的，系统尝试找到与输入单词最相似的单词（我们稍后将讨论如何用Manticore实现）。
  • 或者基于与您的数据无关的外部词典。这里可能出现的问题是您的数据和外部词典差异过大：词典中可能缺少某些单词，而您的数据中可能缺少其他单词。
• 不仅基于词典，还基于上下文，例如，“white ber”会被纠正为“white bear”，而“dark ber”会被纠正为“dark beer”。上下文不仅可能是查询中的相邻单词，还可能是您的位置、时间、当前句子的语法（是否将“there”改为“their”）、您的搜索历史，以及几乎任何可能影响您意图的因素。
• 另一种经典方法是使用之前的搜索查询作为拼写纠正的数据集。这在自动补全功能中使用得更多，但对自动纠正也有意义。其思想是用户大多数拼写是正确的，因此我们可以使用他们的搜索历史中的单词作为事实来源，即使我们在文档中没有这些单词或不使用外部词典。这里也可以实现上下文感知。

Manticore提供了模糊搜索选项以及可用于自动拼写纠正的命令CALL QSUGGEST和CALL SUGGEST。

模糊搜索功能允许通过考虑搜索查询中的轻微变体或拼写错误，实现更灵活的匹配。它的工作方式类似于普通的SELECT SQL语句或/search JSON请求，但提供了额外的参数来控制模糊匹配行为。

注意：fuzzy选项需要Manticore Buddy。如果不起作用，请确保已安装Buddy。

注意：fuzzy选项不适用于多查询。

SELECT
  ...
  MATCH('...')
  ...
  OPTION fuzzy={0|1}
  [, distance=N]
  [, preserve={0|1}]
  [, layouts='{be,bg,br,ch,de,dk,es,fr,uk,gr,it,no,pt,ru,se,ua,us}']
}

SELECT * FROM mytable WHERE MATCH('someting') OPTION fuzzy=1, layouts='us,ua', distance=2;

SELECT * FROM mytable WHERE MATCH('someting') OPTION fuzzy=1 AND (category='books' AND price < 20);

POST /search
{
  "table": "test",
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "*": "ghbdtn"
          }
        }
      ]
    }
  },
  "options": {
    "fuzzy": true,
    "layouts": ["us", "ru"],
    "distance": 2
  }
}

SELECT * FROM mytable WHERE MATCH('hello wrld') OPTION fuzzy=1, preserve=1;

POST /search
{
  "table": "test",
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "*": "hello wrld"
          }
        }
      ]
    }
  },
  "options": {
    "fuzzy": true,
    "preserve": 1
  }
}

+------+-------------+
| id   | content     |
+------+-------------+
|    1 | something   |
|    2 | some thing  |
+------+-------------+
2 rows in set (0.00 sec)

+------+-------------+
| id   | content     |
+------+-------------+
|    1 | hello wrld  |
|    2 | hello world |
+------+-------------+
2 rows in set (0.00 sec)

POST /search
{
  "table": "table_name",
  "query": {
    <full-text query>
  },
  "options": {
    "fuzzy": {true|false}
    [,"layouts": ["be","bg","br","ch","de","dk","es","fr","uk","gr","it","no","pt","ru","se","ua","us"]]
    [,"distance": N]
    [,"preserve": {0|1}]
  }
}

注意：如果您使用query_string，请注意它不支持除短语搜索操作符之外的全文操作符。查询字符串应仅由您希望匹配的单词组成。

• fuzzy：开启或关闭模糊搜索。
• distance：设置匹配的Levenshtein距离。默认值为2。
• preserve：0或1（默认：0）。设置为1时，保留搜索结果中没有模糊匹配的单词（例如，“hello wrld”返回“hello wrld”和“hello world”）。设置为0时，仅返回成功模糊匹配的单词（例如，“hello wrld”仅返回“hello world”）。对于保留可能不存在于Manticore Search中的短词或专有名词特别有用。
• layouts：用于检测因键盘布局不匹配导致的输入错误的键盘布局（例如，使用错误布局时输入“ghbdtn”代替“привет”）。Manticore比较不同布局中字符的位置以建议纠正。至少需要2个布局才能有效检测不匹配。默认不使用任何布局。使用空字符串''（SQL）或空数组[]（JSON）关闭此功能。支持的布局包括：
  • be - 比利时AZERTY布局
  • bg - 标准保加利亚布局
  • br - 巴西QWERTY布局
  • ch - 瑞士QWERTZ布局
  • de - 德国QWERTZ布局
  • dk - 丹麦QWERTY布局
  • es - 西班牙QWERTY布局
  • fr - 法国AZERTY布局
  • uk - 英国QWERTY布局
  • gr - 希腊QWERTY布局
  • it - 意大利QWERTY布局
  • no - 挪威QWERTY布局
  • pt - 葡萄牙QWERTY布局
  • ru - 俄罗斯JCUKEN布局
  • se - 瑞典QWERTY布局
  • ua - 乌克兰JCUKEN布局
  • us - 美国QWERTY布局

• 此演示展示了模糊搜索功能：
• 关于模糊搜索和自动补全的博客文章 - https://manticoresearch.com/blog/new-fuzzy-search-and-autocomplete/

这两个命令都可以通过 SQL 访问，支持查询本地（普通和实时）以及分布式表。语法如下：

CALL QSUGGEST(<word or words>, <table name> [,options])
CALL SUGGEST(<word or words>, <table name> [,options])
options: N as option_name[, M as another_option, ...]

这些命令为给定单词提供字典中的所有建议。它们仅在启用了infixing且设置了dict=keywords的表上工作。它们返回建议的关键词、建议关键词与原始关键词之间的 Levenshtein 距离，以及建议关键词的文档统计信息。

如果第一个参数包含多个单词，则：

• CALL QSUGGEST 只返回最后一个单词的建议，忽略其余部分。
• CALL SUGGEST 只返回第一个单词的建议。

这就是它们之间唯一的区别。支持多种选项进行自定义：

为了展示其工作原理，我们创建一个表并添加几个文档。

create table products(title text) min_infix_len='2';
insert into products values (0,'Crossbody Bag with Tassel'), (0,'microfiber sheet set'), (0,'Pet Hair Remover Glove');

call suggest('crossbudy', 'products');

+-----------+----------+------+
| suggest   | distance | docs |
+-----------+----------+------+
| crossbody | 1        | 1    |
+-----------+----------+------+

call suggest('bagg with tasel', 'products');

+---------+----------+------+
| suggest | distance | docs |
+---------+----------+------+
| bag     | 1        | 1    |
+---------+----------+------+

CALL QSUGGEST('bagg with tasel', 'products');

+---------+----------+------+
| suggest | distance | docs |
+---------+----------+------+
| tassel  | 1        | 1    |
+---------+----------+------+

CALL QSUGGEST('bag with tasel', 'products', 1 as sentence);

+-------------------+----------+------+
| suggest           | distance | docs |
+-------------------+----------+------+
| bag with tassel   | 1        | 1    |
+-------------------+----------+------+

1 as result_line 选项改变了建议在输出中的显示方式。它不再将每个建议显示在单独的行中，而是将所有建议、距离和文档数显示在一行中。以下示例演示了这一点：

CALL QSUGGEST('bagg with tasel', 'products', 1 as result_line);

+----------+--------+
| name     | value  |
+----------+--------+
| suggests | tassel |
| distance | 1      |
| docs     | 1      |
+----------+--------+

force_bigrams 选项可以帮助处理字符调换错误的单词，例如 "ipohne" 与 "iphone"。通过使用二元组而非三元组，算法能更好地处理字符调换。

CALL SUGGEST('ipohne', 'products', 1 as force_bigrams);

+--------+----------+------+
| suggest| distance | docs |
+--------+----------+------+
| iphone | 2        | 1    |
+--------+----------+------+

• 此交互式课程 展示了 CALL SUGGEST 在一个小型网页应用中的工作方式。

查询缓存将压缩的结果集存储在内存中，并在可能的情况下重用它们以响应后续查询。您可以使用以下指令进行配置：

• qcache_max_bytes，缓存查询存储的 RAM 使用限制。默认值为 16 MB。将 qcache_max_bytes 设置为 0 会完全禁用查询缓存。
• qcache_thresh_msec，缓存的最小查询耗时。完成时间快于此值的查询将不会被缓存。默认值为 3000 毫秒，即 3 秒。
• qcache_ttl_sec，缓存条目的 TTL（存活时间）。查询结果将缓存此时长。默认值为 60 秒，即 1 分钟。

这些设置可以通过 SET GLOBAL 语句动态更改：

mysql> SET GLOBAL qcache_max_bytes=128000000;

这些更改会立即生效，不再满足约束条件的缓存结果集会立即被丢弃。在动态减少缓存大小时，最近最常使用（MRU）的结果集优先保留。

查询缓存的工作原理如下。启用时，每个全文搜索结果都会完整存储在内存中。这发生在全文匹配、过滤和排序之后，基本上我们存储了 total_found 个 {docid,weight} 对。压缩后的匹配项平均每个占用 2 到 12 字节，主要取决于相邻 docid 之间的差值。查询完成后，我们检查耗时和大小阈值，决定是保存压缩结果集以供重用，还是丢弃它。

请注意，查询缓存对 RAM 的影响不限于 qcache_max_bytes！例如，如果您同时运行 10 个并发查询，每个查询匹配最多 100 万条结果（过滤后），即使查询足够快且未被缓存，峰值临时 RAM 使用量也会在 40 MB 到 240 MB 之间。

当表、全文查询（即 MATCH() 内容）和排序器完全匹配且过滤条件兼容时，查询可以使用缓存。这意味着：

• MATCH() 中的全文部分必须逐字节匹配。添加一个额外空格，查询缓存就会认为这是一个不同的查询。
• 排序器（及其参数，如果是用户定义的排序器）必须逐字节匹配。
• 过滤条件必须是原始过滤条件的超集。您可以添加额外的过滤条件仍然命中缓存。（在这种情况下，额外的过滤条件会应用于缓存结果。）但如果移除其中一个过滤条件，则会被视为新查询。

缓存条目会根据 TTL 过期，并且在表轮换、TRUNCATE 或 ATTACH 时失效。请注意，目前条目不会因任意 RT 表写入而失效！因此，缓存查询可能在其 TTL 期间返回较旧的结果。

您可以通过 SHOW STATUS 查看当前缓存状态，相关变量以 qcache_XXX 命名：

mysql> SHOW STATUS LIKE 'qcache%';
+-----------------------+----------+
| Counter               | Value    |
+-----------------------+----------+
| qcache_max_bytes      | 16777216 |
| qcache_thresh_msec    | 3000     |
| qcache_ttl_sec        | 60       |
| qcache_cached_queries | 0        |
| qcache_used_bytes     | 0        |
| qcache_hits           | 0        |
+-----------------------+----------+
6 rows in set (0.00 sec)

排序规则主要影响字符串属性的比较。它们定义了字符集编码以及 Manticore 在执行涉及字符串属性的 ORDER BY 或 GROUP BY 时用于比较字符串的策略。

字符串属性在索引时按原样存储，并且不附加任何字符集或语言信息。只要 Manticore 仅需将字符串逐字存储并返回给调用应用程序，这种方式是可行的。然而，当你要求 Manticore 按字符串值排序时，请求立即变得模糊不清。

首先，单字节（ASCII、ISO-8859-1 或 Windows-1251）字符串需要与 UTF-8 字符串不同地处理，后者可能用可变字节数编码每个字符。因此，我们需要知道字符集类型，以便正确地将原始字节解释为有意义的字符。

其次，我们还需要知道特定语言的字符串排序规则。例如，在 en_US 区域设置中按美国规则排序时，带变音符的字符 ï（带分音符的小写字母 i）应放在 z 之后的某处。然而，在考虑法语规则和 fr_FR 区域设置时，它应放在 i 和 j 之间。其他规则集可能会完全忽略变音符，使 ï 和 i 可以任意混合。

第三，在某些情况下，我们可能需要区分大小写的排序，而在其他情况下，则需要不区分大小写的排序。

排序规则封装了以下所有内容：字符集、语言规则和大小写敏感性。Manticore 目前提供四种排序规则：

1. libc_ci
2. libc_cs
3. utf8_general_ci
4. binary

前两种排序规则依赖于多个标准 C 库（libc）调用，因此可以支持系统上安装的任何区域设置。它们分别提供不区分大小写（_ci）和区分大小写（_cs）的比较。默认情况下，它们使用 C 区域设置，实际上是按字节比较。要更改此设置，需要使用 collation_libc_locale 指令指定不同的可用区域设置。系统上可用的区域设置列表通常可以通过 locale 命令获得：

$ locale -a
C
en_AG
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NG
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
es_ES
fr_FR
POSIX
ru_RU.utf8
ru_UA.utf8

具体的系统区域设置列表可能有所不同。请查阅操作系统文档以安装所需的额外区域设置。

utf8_general_ci 和 binary 区域设置内置于 Manticore。第一种是针对 UTF-8 数据的通用排序规则（没有所谓的语言定制）；其行为应类似于 MySQL 中的 utf8_general_ci 排序规则。第二种是简单的按字节比较。

排序规则可以通过 SQL 在每个会话基础上使用 SET collation_connection 语句覆盖。所有后续的 SQL 查询将使用该排序规则。否则，所有查询将使用服务器默认排序规则，或使用 collation_server 配置指令中指定的排序规则。Manticore 目前默认使用 libc_ci 排序规则。

排序规则影响所有字符串属性的比较，包括 ORDER BY 和 GROUP BY 中的比较，因此根据所选排序规则，可能返回不同排序或分组的结果。请注意，排序规则不影响全文搜索；全文搜索请使用 charset_table。

当 Manticore 执行全扫描查询时，它可以使用普通扫描来检查每个文档是否符合过滤条件，或者采用额外的数据和/或算法来加速查询执行。Manticore 使用基于成本的优化器（CBO），也称为“查询优化器”，来决定采用哪种方法。

CBO 还可以提升全文查询的性能。详情见下文。

如果 CBO 认为替换一个或多个查询过滤器能提升性能，它可能会用以下实体之一替换：

1. docid 索引 利用存储在 .spt 扩展名文件中的特殊仅包含 docid 的二级索引。除了提升文档 ID 上的过滤器性能外，docid 索引还用于加速文档 ID 到行 ID 的查找，以及加快守护进程启动时大规模 killlist 的应用。
2. 列式扫描 依赖于列式存储，仅能用于列式属性。它扫描每个值并对其进行过滤测试，但经过高度优化，通常比默认方法更快。
3. 二级索引 默认为所有属性（除 JSON 外）生成。它们使用 PGM 索引 以及 Manticore 内置的倒排索引来检索对应于某个值或值范围的行 ID 列表。二级索引存储在扩展名为 .spidx 和 .spjidx 的文件中。 有关如何为 JSON 属性生成二级索引的信息，请参见 json_secondary_indexes。

优化器使用各种属性统计信息来估算每条执行路径的成本，包括：

1. 属性内数据分布信息（直方图，存储在 .sphi 文件中）。直方图在数据索引时自动生成，是 CBO 的主要信息来源。
2. 来自 PGM（二级索引）的信息，有助于估算需要读取的文档列表数量。这有助于评估文档列表合并性能并选择合适的合并算法（优先队列合并或位图合并）。
3. 列式编码统计，用于估算列式数据解压性能。
4. 列式最小-最大树。虽然 CBO 使用直方图估算应用过滤器后剩余的文档数量，但它还需要确定过滤器处理了多少文档。对于列式属性，部分评估最小-最大树可实现此目的。
5. 全文字典。CBO 利用词项统计信息来估算全文树的评估成本。

优化器计算查询中每个过滤器的执行成本。由于某些过滤器可以被多种不同实体替代（例如，对于文档 ID，Manticore 可以使用普通扫描、docid 索引查找、列式扫描（如果文档 ID 是列式的）和二级索引），优化器会评估所有可用组合。但组合数最大限制为 1024。

为了估算查询执行成本，优化器计算执行查询时最重要操作的估计成本。它使用预设常数来表示每个操作的成本。

优化器比较每条执行路径的成本，选择成本最低的路径来执行查询。

在处理带有属性过滤器的全文查询时，查询优化器在两种可能的执行路径之间做出决定。一种是执行全文查询，检索匹配项，然后使用过滤器。另一种是用上述一个或多个实体替换过滤器，从中获取行 ID 并注入全文匹配树。这样，全文搜索结果将与全扫描结果相交。查询优化器估算全文树评估的成本和计算过滤器结果的最佳路径。基于此信息，优化器选择执行路径。

另一个需要考虑的因素是多线程查询执行（当启用 pseudo_sharding 时）。CBO 知道某些查询可以多线程执行，并将此纳入考虑。CBO 优先考虑较短的查询执行时间（即延迟）而非吞吐量。例如，如果使用列式扫描的查询可以多线程执行（占用多个 CPU 核心），且比单线程使用二级索引执行的查询更快，则优先选择多线程执行。

使用二级索引和 docid 索引的查询始终在单线程中运行，因为基准测试表明使它们多线程几乎没有收益。

目前，优化器仅使用 CPU 成本，不考虑内存或磁盘使用。