索引（B+ 树 / 覆盖 / 失效 / 优化） · 索引数据结构

什么是全文索引（FULLTEXT）？InnoDB 5.6+ 才支持，与 MyISAM 的差异？

What is a FULLTEXT index? Supported in InnoDB 5.6+, what are the

答案语言

考察要点

这道题面试官想看你是否理解非结构化文本搜索的痛点，以及全文索引是如何解决这个问题的。核心考察点包括：

核心原理：是否理解全文索引的基石——倒排索引（Inverted Index），并能与 B+ 树索引做清晰对比。
方案对比：是否清楚 LIKE '%keyword%' 的性能瓶颈，并明白全文索引是其在特定场景下的高效替代方案。
引擎差异：是否掌握 InnoDB 和 MyISAM 在实现全文索引时的关键区别，这能体现你知识的深度和广度，尤其是在事务、并发和实现细节上。

核心概念

全文索引（Full-Text Search, FTS）是一种专门用于在大量文本数据中快速查找关键词的技术。它与我们常用的 B+ 树索引有着本质的不同。

1. 为什么需要全文索引？

常规的 B+ 树索引非常适合精确匹配、前缀匹配（LIKE 'key%'）和范围查询，但对于文本内容中部的关键词搜索（LIKE '%key%'）则无能为力，会导致索引失效和全表扫描，性能极差。

2. 核心数据结构：倒排索引（Inverted Index）

全文索引不存储列的原始值，而是通过“分词”将文本内容拆分成一个个的单词（Token），然后建立一个“单词”到“文档ID列表”的映射关系。这个映射结构就是倒排索引。

数据示例： 假设我们有一个 articles 表：

doc_id	content
1	MySQL is a relational database.
2	`InnoDB` is a storage engine for MySQL.
3	Full-text search is fast.

其对应的倒排索引（简化版）如下：

word	doc_id list
`mysql`	{1, 2}
`database`	{1}
`innodb`	{2}
`engine`	{2}
`search`	{3}
`fast`	{3}
...	...

当执行 MATCH(content) AGAINST('mysql') 时，引擎直接查询倒排索引，找到 mysql 这个词，立即获得其所在的文档 ID 列表 {1, 2}，定位到记录，无需扫描全表。

3. 关键组成部分

分词器 (Parser)：负责将文本块拆分成单词。MySQL 内置了 n-gram 分词器（支持中文、日文、韩文等 CJK 语言）和基于空格的分词器。
停用词 (Stopwords)：一些非常常见但无助于搜索的词（如 "a", "the", "is"）会被忽略，以减小索引大小和提高查询效率。
查询语法：使用 MATCH(column) AGAINST('keywords' [IN BOOLEAN MODE]) 进行查询。

4. `InnoDB` 与 `MyISAM` 的全文索引差异

InnoDB 从 5.6 版本开始支持全文索引，并在后续版本中不断增强。它与 MyISAM 的实现有显著不同：

特性	`MyISAM` 全文索引	`InnoDB` 全文索引 (5.6+)	关键解读
事务支持	不支持	支持 (`ACID`)	这是最重要的区别。`InnoDB` 可以在事务中安全地更新和查询全文索引。
实现机制	索引和数据分离，FTS 索引存储在 `.MYI` 文件中。	索引与数据紧密集成。使用一系列内部的辅助表（`FTS_*_INDEX` 等）来存储倒排索引，这些表本身也是 `InnoDB` 表。	`InnoDB` 的实现更复杂但更健壮，与缓冲池（Buffer Pool）等机制集成得更好。
并发性能	表级锁，写操作会阻塞读操作，并发性能差。	行级锁，写操作通常不阻塞 `MATCH...AGAINST` 查询，并发性能高。	在高并发读写场景下，`InnoDB` 是唯一选择。
数据同步	DML 操作后，索引通常是实时更新的。	异步更新。DML 发生后，变更先放入 FTS 索引缓存，再通过后台线程批量合并到磁盘上的辅助表中。	`InnoDB` 的异步机制提升了写入性能，但可能导致新插入的数据有秒级延迟才能被搜到。
FTS 文档 ID	隐式使用行号或内部指针。	引入一个隐藏的 `FTS_DOC_ID` 列。当表上创建全文索引时，会自动添加此列。	理解 `FTS_DOC_ID` 的存在有助于排查问题和理解其内部工作方式。
CJK 支持	需要通过外部插件或修改源码支持。	MySQL 5.7.6+ 内置 `n-gram` 解析器，开箱即用地支持中文、日文、韩文。	`InnoDB` 在处理亚洲语言方面更为便捷和现代化。

DDL 示例：

sql

 1-- 创建带全文索引的表 (InnoDB)
 2CREATE TABLE articles (
 3    id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
 4    title VARCHAR(200),
 5    body TEXT,
 6    FULLTEXT KEY ft_index (title, body) WITH PARSER ngram -- 使用 n-gram 支持中文
 7) ENGINE=InnoDB;
 8
 9-- 使用全文索引查询
10SELECT * FROM articles
11WHERE MATCH(title, body) AGAINST('数据库 性能' IN NATURAL LANGUAGE MODE);

常见低分回答

“全文索引就是用来替代 LIKE 的”：过于笼统。没有说清楚是替代 LIKE '%keyword%' 这种无法利用 B+ 树索引的场景。而 LIKE 'keyword%' 是可以走索引的。
“全文索引比 LIKE 快”：没有解释快的根本原因在于数据结构不同（倒排索引 vs 全表扫描），这会让面试官觉得你只知其然，不知其所以然。
混淆 InnoDB 和 MyISAM 的特性：例如说“全文索引会锁表”，这在 MyISAM 上是正确的，但在 InnoDB 上则不正确，体现了知识体系陈旧或不精确。
忽略中文分词问题：在被问到实际应用时，如果想不到中文、日文等语言没有天然空格，需要特殊分词器（如 n-gram）才能正确工作，说明缺乏实际工程经验。
对 MATCH...AGAINST 语法不熟：无法写出正确的查询语句，或者不知道 IN BOOLEAN MODE 等高级模式。

工程实践与优化

场景选择：MySQL 的全文索引非常适合中小型应用内的“站内搜索”功能，它避免了引入外部搜索引擎（如 Elasticsearch）的复杂性和维护成本。但对于海量数据、高并发、需要复杂相关性排序和聚合分析的专业搜索场景，Elasticsearch/OpenSearch 是更优解。
索引设计：
- 将需要搜索的多个文本字段（如 title, body, tags）合并到一个全文索引中，可以一次性搜索所有相关字段。
- 对于 CJK 语言，务必使用 WITH PARSER ngram，并可根据业务调整 ngram_token_size（默认为 2）。
参数调优：
- innodb_ft_min_token_size / ft_min_word_len：控制被索引的最小单词长度，默认为 3 或 4。如果需要搜索更短的词，需要调小此参数并重建索引。
- innodb_ft_server_stopword_table：可以自定义停用词表，排除业务领域内的高频无用词，或保留一些被默认禁用的重要词。
查询优化：
- 使用 IN BOOLEAN MODE 可以实现更复杂的逻辑，如 + (AND), - (NOT), * (通配符)。例如 AGAINST('+MySQL -MariaDB' IN BOOLEAN MODE)。
- EXPLAIN 分析 MATCH...AGAINST 查询时，type 列会显示 fulltext。
监控与维护：InnoDB 的全文索引更新是异步的，会消耗后台资源。注意监控 I/O 和 CPU 使用情况，尤其是在大量文本数据写入后。可以通过查询 INFORMATION_SCHEMA.INNODB_FT_* 系列的表来获取全文索引的状态信息。

常见追问与延伸题目

追问：既然 InnoDB 这么好，为什么还有人用 Elasticsearch？MySQL FTS 的局限性在哪？
- 回答要点 1 (功能与生态)：Elasticsearch 是专业的分布式搜索引擎，提供远比 MySQL FTS 丰富的搜索功能，如复杂的聚合、地理位置搜索、更高级的相关性排序算法（BM25）、同义词处理、拼写纠错等。它的生态（Kibana, Logstash）也更完善。
- 回答要点 2 (扩展性与性能)：ES 天生为分布式设计，可以轻松水平扩展到 PB 级数据和极高的查询吞吐量。MySQL FTS 的扩展能力受限于单个数据库实例的垂直扩展能力，当数据量和并发量达到一定级别后，性能会成为瓶颈。
- 回答要点 3 (资源隔离)：将搜索负载从核心业务数据库（MySQL）剥离到独立的 ES 集群，可以避免高强度的搜索请求影响核心事务处理的性能和稳定性，实现资源隔离。
追问：当 INSERT 一条新数据后，为什么有时候 MATCH...AGAINST 查不到？这和事务有什么关系？
- 回答要点 1 (异步同步机制)：这是因为 InnoDB 全文索引的异步更新机制。INSERT 成功仅代表数据写入了主表并提交了事务。但全文索引的更新是先写入内存缓存，再由后台线程批量、延迟地同步到磁盘上的倒排索引辅助表。这个延迟通常是秒级，但高负载下可能更长。
- 回答要点 2 (与事务的关系)：事务保证的是主表数据的ACID。即使事务已 COMMIT，全文索引的“最终一致性”也可能尚未完成。这是一个需要向业务方解释清楚的特性，即“数据写入成功，但搜索可见性有短暂延迟”。MyISAM 因为不支持事务且索引更新更直接，较少遇到此问题，但代价是极差的写入并发。
追问：如果让你设计一个支持中文的全文索引，n-gram 方式有什么优缺点？还有其他方案吗？
- 回答要点 1 (n-gram 优点)：实现简单、无需词典。它通过机械地切分字符，对新词、网络用语有很好的兼容性，不依赖于维护一个庞大的词库。对于 MySQL 来说，这是内置的最佳选择。
- 回答要点 2 (n-gram 缺点)：索引膨胀和查询不精确。一个词会被切分成多个 token，导致索引体积增大。例如 N=2 时，“数据库”被切成“数据”和“据库”，搜索“数据库”时，包含“数据仓库”的文档也可能因为匹配到“数据”而被召回，影响精度。
- 回答要点 3 (其他方案)：更专业的方案是基于词典的分词，如使用 jieba、IK Analyzer 等工具。这种方法能准确地切分出有意义的词语（如“数据库”被切成一个整体），查询精度高。但在 MySQL 中使用需要通过插件或在应用层预先分词后存入特定字段，增加了系统复杂度。Elasticsearch 则原生支持这类高级分词器。