mysql 5.7 innodb中文全文索引表现更好，是因为引入ngram解析器并深度集成事务、锁和缓存机制；它不依赖语义分词，而是通过滑动窗口切字（如ngram_token_size=2生成“数据”“据库”），需显式指定with parser ngram、正确配置innodb_ft_min_token_size等参数才能生效。
INNODB 全文索引在中文环境下“表现更好”，不是因为它天生更懂中文，而是因为 MySQL 5.7 引入了 ngram 解析器，并与 InnoDB 的事务、锁和缓存机制做了深度协同。单纯比单次查询延迟，它未必快过 LIKE 或 MyISAM；但综合写入吞吐、并发安全、崩溃恢复和可维护性，它才是生产环境里真正能用的方案。
为什么必须显式指定 WITH PARSER ngram
MySQL 默认的全文解析器是空格分词（mechanical），对中文完全无效——它会把整段中文当做一个超长 token，然后被 innodb_ft_max_token_size（默认 84）截断或直接丢弃。
不加 WITH PARSER ngram，哪怕字段全是中文，CREATE FULLTEXT INDEX 也能成功，但后续 MATCH ... AGAINST 基本查不到结果。
常见错误现象：MATCH(title) AGAINST('数据库') 返回空，但 LIKE '%数据库%' 能查到——说明索引建了，但没分出有效词项。
ngram_token_size 设为 1 还是 2？取决于你的业务关键词粒度
这个值决定中文切分窗口大小：
• ngram_token_size = 1：切出所有单字，如“数据库” → “数”、“据”、“库”。适合搜人名、地名缩写，但倒排表体积暴增，I/O 压力大。
• ngram_token_size = 2（默认）：切出两字组合，“数据库” → “数据”、“库”（注意末尾单字会被丢弃）。覆盖大多数常用词，索引体积可控。
• ngram_token_size = 3：适合专业术语多的场景，如“关系型数据库”，但漏掉“数据”“库”等短词，召回率下降。
调整后需重启 MySQL 才生效，且已有全文索引不会自动重建——必须 DROP INDEX 后重加。
为什么 MATCH ... AGAINST 查询变慢甚至失效？几个关键配置漏不得
中文全文索引不是建完就万事大吉，以下参数错一个，性能或功能就打折：
• innodb_ft_min_token_size 必须 ≤ ngram_token_size，否则切出来的 n-gram 会被过滤掉（默认是 3，若设 ngram_token_size=2 却不调低它，所有二元词全丢）
• innodb_ft_enable_stopword = OFF（可选）：中文停用词表默认启用，但内置停用词极少，自定义停用词表需提前创建并指向 innodb_ft_user_stopword_table
• innodb_optimize_fulltext_only = ON：否则 OPTIMIZE TABLE 不合并倒排索引碎片，长期运行后查询越来越慢
• FTS_DOC_ID 字段必须存在且为 BIGINT UNSIGNED NOT NULL，并带唯一索引，否则建全文索引直接报错
怎么确认倒排索引真被用了？别信 EXPLAIN 的 type: fulltext
EXPLAIN 显示 type: fulltext 只代表语法合法、索引存在，不代表实际走倒排查找。
真正验证方式：
• 开启调试日志：SET GLOBAL innodb_ft_enable_diag_print = ON，然后执行查询，看错误日志里是否出现 fts_search 调用轨迹（注意：仅限测试环境，线上勿开）
• 查看 INFORMATION_SCHEMA.INNODB_FT_INDEX_TABLE，如果该表有对应分词记录，说明倒排已生成
• 对比查询耗时：在百万级数据上，MATCH ... AGAINST 应稳定在几十毫秒内；若仍达秒级，大概率是优化器回退到了表扫描
InnoDB 全文索引只是过渡方案——复杂语义、拼音容错、近义扩展，还是得交给 Elasticsearch 或 OpenSearch。
