MySQL 8.0的InnoDB FTS支持自然语言和布尔模式，而MyISAM仅支持这两种模式但分词简单、无停用词管理、不支持自定义解析器；InnoDB还具备事务安全索引更新、更稳定的相关性评分及复合条件下的索引优化能力。
MySQL 8.0 的 INNODB FTS 支持自然语言模式和布尔模式
MyISAM 的全文索引只支持布尔模式（BOOLEAN MODE）和自然语言模式（NATURAL LANGUAGE MODE），但其分词逻辑简单、无停用词管理、不支持词干提取，且无法自定义解析器。InnoDB 在 MySQL 5.6 引入 FTS 后持续迭代，到 8.0 已支持：innodb_ft_parser 插件机制、可配置停用词表（innodb_ft_default_stopword 可替换）、支持用户自定义全文解析器（如 ngram、MeCab）、并默认启用词干处理（如英文的 “running” → “run”）。这意味着同样一条 SELECT ... MATCH AGAINST('running' IN NATURAL LANGUAGE MODE)，InnoDB 能命中更多语义相关行，MyISAM 则严格匹配字面。
INNODB FTS 索引更新是事务安全的，不会导致索引与数据不一致
MyISAM 全文索引在 INSERT/UPDATE 后立即生效，但崩溃时可能丢失索引变更（因无 redo 日志），需手动 REPAIR TABLE；而 InnoDB 的 FTS 更新被纳入事务日志体系：插入带全文字段的记录时，变更先写入 FTS_INDEX_TABLE（内部辅助表），再通过后台线程合并进主 FTS 索引，整个过程受 COMMIT 控制。这意味着：
- 事务回滚时，FTS 索引变更自动撤销
- 主从复制中，FTS 索引状态与数据严格一致
- 不会出现 MyISAM 常见的 “
Can't find FULLTEXT index matching the column list” 错误（该错误常因索引损坏或元数据不同步引发）
INNODB FTS 查询结果支持排序与相关性评分，且评分更稳定
MyISAM 的 MATCH ... AGAINST() 返回的相关性分数（relevance score）基于词频和文档长度粗略估算，且受表锁影响——并发写入时分数可能突变；InnoDB 的评分算法更精细（引入 IDF 加权、字段权重、短语匹配加分等），更重要的是：INNODB FTS 的评分计算发生在 MVCC 快照内，不受其他事务未提交修改干扰。例如执行 SELECT *, MATCH(title) AGAINST('database' IN NATURAL LANGUAGE MODE) AS score FROM articles ORDER BY score DESC LIMIT 10，InnoDB 每次返回的 top 10 排序更可预期，MyISAM 在高并发写入场景下可能出现同一查询两次结果顺序不一致。
MyISAM 全文索引无法在 WHERE + ORDER BY + LIMIT 场景下高效利用索引
MyISAM 的全文索引无法与其他条件组合使用优化执行计划。比如 SELECT * FROM logs WHERE status = 'error' AND MATCH(msg) AGAINST('timeout') ORDER BY created_at DESC LIMIT 20，MyISAM 往往放弃全文索引，退化为全表扫描后过滤；而 InnoDB 在 8.0 中支持复合条件下的索引合并（index merge）与覆盖扫描，只要 status 有普通索引、msg 有 FTS 索引，优化器大概率选择 FTS + ref 执行路径。实际慢查询日志里常见 type: fulltext 配合 Extra: Using where; Using filesort 的 MyISAM 记录，InnoDB 则多为 type: ft + Extra: Using filesort（filesort 可避免，加 created_at 覆盖索引即可）。
真正容易被忽略的是：InnoDB FTS 的 innodb_ft_min_token_size 和 innodb_ft_max_token_size 默认值（分别为 3 和 84）比 MyISAM 的 ft_min_word_len（默认 4）更宽松，且可在线调整；但若业务大量使用短词（如缩写、代码标识符），不调低 innodb_ft_min_token_size，就会漏建索引项——这点连很多 DBA 都会漏查。
