MySQL 5.7 InnoDB全文索引并非天然更快，而是依托事务一致性、行级锁、MVCC和缓冲池等引擎级能力实现可靠高效；其倒排索引存于FTS辅助表（B+树结构），支持增量合并与WAL保护，不同于MyISAM的静态重建。
MySQL 5.7 的 InnoDB 全文索引并不是“天然更高效”，而是相比 MyISAM 的全文索引，在事务一致性、并发写入和崩溃恢复上更可靠；其底层确实用了倒排索引结构，但效率提升的关键不在“倒排”本身，而在于与 InnoDB 存储引擎的深度集成——比如行级锁支持、MVCC 隔离、缓冲池缓存能力。单纯比单次查询速度，MyISAM 在只读场景下有时反而更快。
InnoDB 全文索引的倒排结构长什么样
InnoDB 把每个分词（token）映射到包含该词的文档 ID（即 FTS_DOC_ID）列表，并把倒排列表存放在一组隐藏的 FTS auxiliary tables 中（如 fts_0000000000000123_0000000000000456_idx）。这些表是普通的 InnoDB 表，走标准的 B+ 树索引，支持缓冲池缓存和 WAL 日志保护。
这和 MyISAM 手动维护的静态倒排文件不同：MyISAM 的全文索引在插入/更新时需重建整个索引段，而 InnoDB 是增量合并（通过 innodb_fts_insert_modified_sync 和后台线程异步 merge），写入压力小得多。
- 分词器默认用
ngram（中文）或mechanical（英文），不支持自定义分词器 -
FTS_DOC_ID必须存在且为BIGINT UNSIGNED NOT NULL，并建唯一索引；否则CREATE FULLTEXT INDEX会失败 - 倒排项不直接存原始文本，只存文档 ID + 位置偏移（用于
IN NATURAL LANGUAGE MODE排序）
为什么 MATCH ... AGAINST 在某些场景变慢了
常见现象：加了全文索引后，MATCH(title, content) AGAINST('数据库' IN NATURAL LANGUAGE MODE) 查询响应时间反而比 LIKE '%数据库%' 还高。这不是倒排索引失效，而是优化器误判或配置未对齐。
- 默认
innodb_ft_min_token_size = 3，中文分词被截断（“数”“据”“库”全被丢弃），导致查不到结果或命中率极低 - 没显式指定
ngramparser：CREATE FULLTEXT INDEX ft_idx ON articles(content) WITH PARSER ngram - 查询词长度低于
innodb_ft_max_token_size（默认 84），但字段实际含大量超长词，倒排表膨胀，I/O 增加 -
innodb_optimize_fulltext_only = OFF（默认），导致OPTIMIZE TABLE不触发倒排索引合并，碎片堆积
如何验证倒排索引是否真被用了
不能只看 EXPLAIN 是否显示 type: fulltext ——那只是说明语法合法。真正要看执行路径是否绕过表扫描：
- 开启
innodb_ft_enable_diag_print = ON（仅调试环境），观察错误日志里是否有fts_search调用轨迹 - 对比
SELECT COUNT(*) FROM information_schema.INNODB_FT_INDEX_TABLE WHERE WORD = '数据库'是否返回非零值（确认词已入倒排） - 用
SHOW ENGINE INNODB STATUS\G查看FULLTEXT INDEXES小节，确认total document count和total word count合理增长 - 禁用全文索引强制走
LIKE：加IGNORE INDEX (ft_idx)，再比对Handler_read_rnd_next值是否飙升（说明原查询确实在用索引跳过大量行）
倒排索引本身不解决语义歧义或分词质量，InnoDB 的优势在于它把全文检索“关进了事务牢笼”——你不会在主从延迟时看到从库搜不到刚提交的内容，也不会因崩溃丢失倒排条目。但如果你的业务需要高精度中文分词、同义词扩展或拼音模糊匹配，InnoDB 内置全文仍是玩具级方案，该上 Elasticsearch 的时候别硬扛。
