MySQL 8.0 不支持原生倒排索引，实际可用的是 FULLTEXT 索引（底层为倒排结构）；必须配合 ngram 插件处理中文、建联合索引实现前置过滤、禁用停用词并调小最小词长，且查询必须用 MATCH() AGAINST() 语法。
MySQL 8.0 的倒排索引（Inverted Index）不是原生支持的功能——它没有像 Elasticsearch 或 PostgreSQL 的 tsvector 那样的内置倒排结构。你真正能用的，是全文索引（FULLTEXT）或基于普通 B-tree 索引 + 字符串函数的模拟方案。所谓“倒排索引优化”，实际是围绕 MATCH ... AGAINST 查询做针对性调优。
为什么直接建 FULLTEXT 索引后搜索还是慢？
常见现象：建了 ALTER TABLE docs ADD FULLTEXT(title, content)，但 MATCH(title, content) AGAINST('数据库优化' IN NATURAL LANGUAGE MODE) 扫描行数多、响应慢。
-
FULLTEXT在 InnoDB 中依赖内部的倒排词典，但词典构建受innodb_ft_min_token_size（默认 3）和innodb_ft_max_token_size（默认 84）限制；短于 3 的词（如“DB”“SQL”）直接被丢弃，查不到 - 自然语言模式（
NATURAL LANGUAGE MODE）会动态计算相关性，无法走索引下推，EXPLAIN显示type=fulltext但rows常为全表量级 - 布尔模式（
BOOLEAN MODE）支持+/-/*，但若查询含停用词（如“的”“和”），且未关闭停用词表（innodb_ft_enable_stopword=OFF），匹配逻辑会被干扰 -
MATCH只能出现在WHERE最外层，不能嵌套或与其他条件混合使用索引——比如WHERE status = 'published' AND MATCH(...) AGAINST(...)，若没把status加进联合全文索引，status条件就只能过滤结果集，无法缩小扫描范围
如何让 MATCH 查询真正走索引过滤？
关键不是“倒排索引本身”，而是让全文查询和等值/范围条件共用一个联合索引结构。
- 必须建联合全文索引：例如业务常查已发布文档，就建
ALTER TABLE docs ADD FULLTEXT(status, title, content)—— 注意：FULLTEXT索引首列必须是参与MATCH的字段，status放前面才能满足最左前缀，使WHERE status = 'published'先定位数据段 - 确认停用词配置：运行
SELECT @@innodb_ft_enable_stopword;，若为ON且业务需要匹配单字词，需设为OFF并重建索引（ALTER TABLE docs DROP INDEX ft_idx; ALTER TABLE docs ADD FULLTEXT ft_idx(status, title, content);） - 调小最小分词长度：修改
SET GLOBAL innodb_ft_min_token_size = 2;后，必须重启 MySQL 实例并重建所有FULLTEXT索引才生效 - 避免 SELECT *：全文查询本身不返回词频或位置信息，
SELECT MATCH(...) AGAINST(...), title FROM docs...比SELECT *更快，减少回表开销
EXPLAIN 看不到 key，但 Extra 有 Using filesort，说明什么？
这表示全文索引没被用于排序或过滤，只是被当作普通条件参与执行，后续仍需额外排序。
-
EXPLAIN中key为空，type=fulltext但Extra含Using filesort→ 全文匹配结果集太大，MySQL 放弃利用索引顺序，改用临时文件排序 - 根本原因通常是
MATCH返回行数过多（比如查“系统”这种高频词），此时应加强前置过滤：WHERE status = 'active' AND publish_time > '2025-01-01' AND MATCH(...) AGAINST(...)，并确保这些字段都在联合全文索引中靠前位置 - 不要指望
ORDER BY relevance DESC LIMIT 10能自动加速——relevance是计算值，无法索引；如需按相关性取 top-N，必须接受一次小结果集的内存排序，控制MATCH输出行数才是关键
比建 FULLTEXT 更该先做的事
90% 的“全文慢”问题，根源不在索引类型，而在文本预处理和查询写法。
- 检查字段字符集：全文索引要求列是
utf8mb4，且校对规则为utf8mb4_0900_as_cs或兼容变体；若用utf8mb4_general_ci，某些 emoji 或扩展汉字可能分词异常 - 避免在 MATCH 列上用函数：
MATCH(UPPER(content)) AGAINST(...)永远无法命中任何全文索引 - 不用 LIKE 模拟全文：
WHERE content LIKE '%优化%'不走索引，且无法利用倒排结构，纯属线性扫描 - 大文本字段（如
TEXT）务必启用innodb_large_prefix=ON和ROW_FORMAT=DYNAMIC，否则长文本可能截断导致分词失败
真正有效的倒排能力，在 MySQL 里始终绑定在 FULLTEXT 的实现细节上——它不暴露底层倒排表，也不支持自定义分词器。想获得可控的倒排性能，要么严格按它的规则建索引、调参数、写查询，要么换用专为搜索设计的引擎。别在 CREATE INDEX ... DESC 上浪费时间，那和文本搜索完全无关。
