MySQL · 引擎特性 · InnoDB Fulltext简介

本文主要是介绍MySQL · 引擎特性 · InnoDB Fulltext简介，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

从MySQL5.6版本开始支持InnoDB引擎的全文索引，语法层面上大多数兼容之前MyISAM的全文索引模式。所谓全文索引，是一种通过建立倒排索引，快速匹配文档的方式。MySQL支持三种模式的全文检索模式：

第一种是自然语言模式（IN NATURAL LANGUAGE MODE），即通过MATCH AGAINST 传递某个特定的字符串来进行检索。

第二种是布尔模式（IN BOOLEAN MODE），可以为检索的字符串增加操作符，例如“+”表示必须包含，“-”表示不包含，“*”表示通配符（这种情况，即使传递的字符串较小或出现在停词中，也不会被过滤掉），其他还有很多特殊的布尔操作符，可以通过如下参数控制：

第三种是查询扩展模式（WITH QUERY EXPANSION）, 这种模式是自然语言模式下的一个变种，会执行两次检索，第一次使用给定的短语进行检索，第二次是结合第一次相关性比较高的行进行检索。

目前MySQL支持在CHAR、VARCHAR、TEXT类型的列上定义全文索引。

本文只是简单的分析了全文索引涉及到的代码模块以及5.7的一些新特性，源码部分基于MySQL5.7.8-rc版本。更细节的部分并未深入。

创建全文索引

如下例所示，一个简单的创建带全文索引表的SQL：

磁盘上会产生多个文件：

除了t1.frm和t1.ibd外，共分为以下几类表

a)
FTS_000000000000010b_0000000000000154_INDEX_1~6.ibd这6个文件用于存储倒排索引，存储的是分词和位置以及docment ID，根据分词的第一个字符值进行分区，映射到不同的文件中。

文件的命名规则为FTS_{TABLE_ID}_{INDEX_ID}_INDEX_{N}.ibd

b)
FTS_000000000000010b_DELETED.ibd 包含已经被删除的DOC_ID，但还没从全文索引数据中删掉;
FTS_000000000000010b_DELETED_CACHE.ibd 是前者的内存缓存（但是搜索了下代码，只有当fts_cache_t::deleted_doc_ids被使用时，才会在sync时转储到该表中，但并没有发现任何地方使用这个对象）

c)
FTS_000000000000010b_BEING_DELETED_CACHE.ibd
FTS_000000000000010b_BEING_DELETED.ibd
包含了已经被删除索引记录并且正在从全文索引中移除的DOC ID，前者是后者的内存版本，这两个表主要用于辅助进行OPTIMIZE TABLE时将DELETED/DELETED_CACHED表中的记录转储到其中。

d)
FTS_000000000000010b_CONFIG.ibd
包含全文索引的内部信息，最重要的存储是FTS_SYNCED_DOC_ID，表示已经解析并刷到磁盘的doc id. 在崩溃恢复时，可以根据这个值判断哪些该重新解析并加入到索引cache中。

建全文索引辅助表函数参考：

当对一个已经存在的表上创建全文索引时，InnoDB采用了fork多个线程进行并发构建全文索引项的方法，并发度由参数innodb_ft_sort_pll_degree 控制。因此在restore一个全文索引表时，我们建议先建表、导入数据，再在表上创建全文索引。

参考函数：row_merge_read_clustered_index --> row_fts_start_psort
线程回调函数为fts_parallel_tokenization。

当表上存在全文索引时，就会隐式的建立一个名为FTS_DOC_ID的列，并在其上创建一个唯一索引，用于标识分词出现的记录行。你也可以显式的创建一个名为FTS_DOC_ID的列，但需要和隐式创建的列类型保持一致。

为了维护表上的全文索引信息，全文索引模块定义了大量的类来进行管理，总的来说，如下图所示：

普通DML及查询操作

插入

我们可以通过INNODB_FT_INDEX_CACHE来检查插入记录的分词：

在插入一条记录时，对应的堆栈如下：

在向原表上插入完成记录后，会去判断表上是否有全文索引（DICT_TF2_FTS），如果有的话，则将插入记录对应的doc id提取出来(fts_get_doc_id_from_row)，并缓存到事务对象中。

删除

删除操作不会直接从全文索引里直接删除，因此依然可以从INNODB_FT_INDEX_CACHE中查到分词信息

更新

更新非全文索引列，不会修改FTS_DOC_ID列的值。如果更新了全文索引列，在InnoDB的实现是删除老的DOC，并插入新的DOC

堆栈为：

可见所有DML的操作，都走接口函数fts_trx_add_op，划分为两种操作:FTS_INSERT及FTS_DELETE；当前事务涉及的doc id被存储到trx->fts_trx中，在执行SQL的过程中并没有更新全文索引，而是在事务提交时进行的。

在缓存操作时，维护了两个结构，一个是trx->fts_trx->savepoints，维护了事务全局的全文索引操作，另外一个是trx->fts_trx->last_stmt，维护的是当前SQL操作的doc id，前者在事务结束时处理，后者在SQL结束时清空。

查询

对于全文索引的查询，采用新的接口函数，分为两步

第一步，根据检索词搜集符合条件的doc id

在搜集满足查询条件的doc id时，首先读取DELETED表中记录的doc id，这些doc id随后被用做过滤。

第二步，根据搜集到的doc id，找到对应的记录，使用的索引是dict_table_t::fts_doc_id_index，也就是建立在隐藏列FTS_DOC_ID上的唯一索引。

通常查询返回的结果是根据rank排序的，InnoDB的全文检索排序规则和sphinx类似，基于 BM25 和 TF-IDF算法。

rank的计算算法如下：

IDF的计算参阅函数：fts_query_calculate_idf
ranking计算：fts_query_calculate_ranking

如果使用多个单词匹配到，则把各个单词各自的rank累加起来。官方博客有一篇文章专门对此进行了介绍。

事务操作

事务内回滚
正在事务内回滚某个语句，或者回滚到某个savepoint时，需要将对应的操作记录也要删除。维护了trx->fts_trx->last_stmt，在单条SQL结束时释放(trx_mark_sql_stat_end )。如果SQL回滚，就根据last_stmt中维护的doc id从全局savepoints中清理掉本条SQL的doc id。

同步缓存

在满足一定条件时，全文索引需要进行一次sync操作，将数据同步到全文索引文件中，大概包含以下集中情况需要sync：

cache数据占用的内存超过限制
后台线程fts_optimize_thread在shutdown调用，将所有表进行一次sync。
ha_innobase::optimize调用（执行optimize table）
row_merge_read_clustered_index：创建一个新的临时表并读入数据后，进行一次sync调用

同步操作的入口函数为fts_sync，大体流程为：

针对每个索引，调用函数fts_sync_index：通过函数fts_select_index计算写入的索引文件，再将分词节点信息写入到文件（函数fts_write_node）, 倒排索引的记录内容使用结构体fts_node_t进行描述，存储结构如下图所示：
调用fts_sync_commit提交sync操作：
- 更新CONFIG表记录的最大SYNC的DOC ID（fts_cmp_set_sync_doc_id）；
- 若fts_cache_t::deleted_doc_ids不为空，将其加入到DELETED_CACHE辅助表中（fts_sync_add_deleted_cache）
- 清空cache 并重新初始化

Optimize table

当你修改了某些配置（例如最小token size时），或者希望重组全文索引时，可以执行optimize table。由于原始optimize table操作会产生整个表的重建，耗时太久，因此InnoDB引入了一个参数innodb_optimize_fulltext_only来控制该行为。当开启该选项时，如果执行optimize table，就只优化全文索引，而不会去重建表，入口函数为ha_innobase::optimize：

首先调用函数fts_sync_table，将表上在内存中cache的数据刷到全文索引文件中；
然后调用函数fts_optimize_table，我们主要分析集中在第二步。

fts_optimize_table函数流程如下：

如果BEGING_DELETED表中没有数据（例如第一次调用optimized table），则将DELETED表中的数据转储到BEING_DELETED表中，相当于拿到了一个快照，执行的SQL操作为：

参考函数：fts_optimize_create_deleted_doc_id_snapshot

从BEING_DELETED/BEING_DELETED_CACHE表中读取已经被删除的doc id，这些doc id在随后的索引优化中将被忽略掉。
参考函数：fts_optimize_read_deleted_doc_id_snapshot
调用fts_optimize_indexes 对每个索引进行优化，相关堆栈如下：

当在所有索引上完成optimize后，调用fts_optimize_purge_snapshot，主要操作包括： a)

从DELETE和DELETE_CACHE表中将doc id删除，参考函数fts_optimize_purge_deleted_doc_ids

从BEING_DELETED及BEING_DELETED_CACHE中删除对应的doc id。
参考函数： fts_optimize_purge_deleted_doc_id_snapshot

后台线程

InnoDB启动时，会创建一个后台线程，线程函数为fts_optimize_thread，工作队列为fts_optimize_wq，其主要目的是在满足一定条件时，对表自动进行optimize操作。

在如下两种情况，会向fts_optimize_wq中增加元组：

fts_optimize_add_table: 创建或打开一个新的带全文索引的表时，创建一个类型为FTS_MSG_ADD_TABLE并包含表对象指针的MSG，加入到fts_optimize_wq中，这些表禁止被从数据词典中驱逐。
fts_optimize_remove_table: 删除表、DDL、释放表对象(dict_mem_table_free)、删除全文索引(fts_drop_index)等操作时，会创建一个类型为FTS_MSG_DEL_TABLE的MEG，加入到fts_optimize_wq队列中。

fts optimize线程对于FTS_MSG_ADD_TABLE类型的会将相应的表加入到调度队列，对于FTS_MSG_DEL_TABLE，则从调度队列中删除。其调度队列的成员类型为fts_slot_t。

当表上删除的数据量超过一千万(FTS_OPTIMIZE_THRESHOLD)行时，就会触发一次自动optimize table，但两次optimize的间隔不应低于300秒（FTS_OPTIMIZE_INTERVAL_IN_SECS）。

监控

我们可以通过几个INFORMATION_SCHEMA下的全文索引表来监控全文索引状态。

想要从information_schema表中查询信息，需要先设置变量innodb_ft_aux_table，值为你要查询表的"dbname/tablename"。

全文索引停词

停词(STOP WORD)用于在分词时忽略那些常见的不重要的单词，InnoDB目前内建的停词可以从information_schema.INNODB_FT_DEFAULT_STOPWORD读取，用户也可以自己定义停词列表，方法很简单：创建一个和nformation_schema.INNODB_FT_DEFAULT_STOPWORD一模一样的表，将你想要的停词加入到其中，然后设置innodb_ft_server_stopword_table值为你创建的表名："dbname/tabname"。

你也可以使用会话级别的参数innodb_ft_user_stopword_table来指定你想要的停词表。和上述创建规则一致。具体的参阅官方文档

另外配置项innodb_ft_min_token_size及innodb_ft_max_token_size 用于表示一个单词的字符长度范围，在这个范围的连续字符串才会被当作一个单词。然而如果使用ngram解析器的话，有效单词长度受参数ngram_token_size控制。

可以关闭参数innodb_ft_enable_stopword，这样在分词时也会把预设的停词考虑进去。