MySQL全文索引基于倒排索引，由分词结果、词项文档映射和位置与统计信息三部分构成，通过MATCH() AGAINST()语法实现关键词快速定位，比LIKE "%xxx%"高效但受限于停用词、短词长度及不支持模糊前缀等。
MySQL全文索引的核心是倒排索引，它不按“文档→词语”组织数据，而是反过来建立“词语→文档”的映射关系，从而跳过逐行扫描，实现关键词级的快速定位。
倒排索引怎么构成
它由三部分组成：分词结果、词项文档映射、位置与统计信息。
- 文本先被分词器切分成独立词元（如“数据库优化”拆为“数据库”“优化”），同时过滤停用词（如“的”“和”）、统一大小写、做词干还原（如“running”→“run”）
- 每个词元对应一个倒排条目，记录哪些文档ID包含它，以及在文档内的出现位置（支持短语搜索）
- 索引中还可能存词频（TF）、逆文档频率（IDF）等，用于后续相关性排序
MySQL里怎么用倒排索引
InnoDB 和 MyISAM 都支持全文索引，但实现细节不同。InnoDB 从 5.6 起原生支持，底层也是构建倒排结构，只是索引更新与事务集成更紧密。
- 建表时用 FULLTEXT KEY 显式声明，字段类型需为 CHAR/VARCHAR/TEXT
- 查询必须用 MATCH() AGAINST() 语法，不能用 LIKE 或普通 WHERE
- 默认只索引长度 ≥4 的词（ft_min_word_len=4），短词如“AI”“Go”需调小该参数并重建索引
- 字符集必须兼容（如 utf8mb4），否则分词可能出错或索引失效
为什么比 LIKE "%xxx%" 快
LIKE 带前后通配符会强制全表扫描，而倒排索引让查询变成一次查词表+取文档ID集合，时间复杂度接近 O(1) 查词 + O(k) 取结果（k 是命中文档数）。
- 比如搜“冬奥会”，系统直接查倒排表中“冬奥会”对应的文档 ID 列表，无需读每条 title 字段
- 支持自然语言模式（自动加权）和布尔模式（AND/OR/NOT 组合），还能对结果按相关性排序
- 代价是索引体积大、更新略慢（插入/更新文本时要同步维护倒排结构）
常见限制和注意点
倒排索引不是万能的，实际使用中容易踩坑。
- 停用词列表不可控：MySQL 内置停用词表（如英文的 “the”, “is”），中文需自行配置或用插件扩展
- 不支持模糊前缀（如 “北*”），也不支持正则；想实现类似效果得结合其他方案（如 Ngram 分词或外部搜索引擎）
- 索引重建成本高：修改 ft_min_word_len 或停用词后，必须执行 ALTER TABLE ... REPAIR FULLTEXT 或重建表
- 单字段索引为主，多列联合全文索引存在，但 MATCH 中必须包含全部列，灵活性受限
