mysql 8.0升级后全文索引搜索不准怎么办_重新构建ft_min_word

MySQL 8.0全文索引搜索不准主因是配置变严格：innodb_ft_min_token_size未设为1导致短词被过滤，innodb-ft-server-stopword-table未自定义致停用词拦截，且中文搜索须显式指定ngram解析器并重建索引。

mysql 8.0升级后全文索引搜索不准怎么办_重新构建ft_min_word_len

MySQL 8.0 升级后全文索引搜索不准，大概率不是“坏了”，而是默认配置变严格了——ft_min_word_len 和停用词表这俩参数没同步调整，导致短词、中文、标点附近词全被过滤掉了。

为什么升级后 `ft_min_word_len` 突然不生效了

MySQL 5.7 默认用 ft_min_word_len=4，但 8.0 的 InnoDB 全文索引实际受两个参数共同控制：innodb_ft_min_token_size（InnoDB 层）和 ft_min_word_len（MyISAM 层，对 InnoDB 无效）。升级后若只改了后者，InnoDB 表仍按默认 innodb_ft_min_token_size=3 切词，ok、a、i 这类词直接被丢弃。

innodb_ft_min_token_size 才是 InnoDB 全文索引真正的最小词长，必须设为 1（注意：设为 0 会报错）
ft_min_word_len 对 InnoDB 表完全不起作用，仅保留兼容 MyISAM；删掉或留着都行，但别指望它管用
修改后必须重启 MySQL，且需重建全文索引（ALTER TABLE ... DROP INDEX ...; CREATE FULLTEXT INDEX ...），光 ANALYZE TABLE 不行

停用词表没关，`+what` 这种布尔模式也查不到

MySQL 8.0 默认启用内置停用词表，what、is、ok、an 等常见英文词全在列表里，哪怕加了 + 强制包含，也会被预处理阶段直接剔除。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

不能只靠 ft_stopword_file="" 关闭——这个只影响 MyISAM；InnoDB 停用词由 innodb-ft-server-stopword-table 控制
必须创建一张空表（如 db_stopwords），并用 innodb-ft-server-stopword-table=enbs.cn/db_stopwords 指向它
确认生效：执行 SHOW VARIABLES LIKE 'innodb_ft_server_stopword_table'，输出值必须和配置完全一致（含库名）
改完配置 + 重启 + 重建索引，三步缺一不可

中文搜索结果和 `LIKE` 对不上

InnoDB 默认的全文解析器按空白和标点切词，对中文完全无效，“数据库” 会被当做一个整体 token，但长度超限或含标点就匹配失败。这不是配置问题，是解析器选错了。

必须显式指定 ngram 解析器：CREATE FULLTEXT INDEX ft_cn ON liju (cn) WITH PARSER ngram
ngram 默认 ngram_token_size=2（二元分词），查“数据库”能命中“数据”“库”，但搜单字“数”仍不行；如需单字支持，得在建表时设 WITH PARSER ngram 并调 ngram_token_size=1（性能代价大，慎用）
重建前先 DROP INDEX，否则 CREATE FULLTEXT INDEX 会报错“Duplicate key”
ngram 只支持 IN NATURAL LANGUAGE MODE 和 IN BOOLEAN MODE，不支持 IN QUERY EXPANSION MODE

重建索引后还是不准？先盯住这三个地方

最常被忽略的是字符集与排序规则变化带来的隐性干扰——8.0 默认 utf8mb4_0900_as_cs 区分大小写和重音，而旧数据可能是 utf8mb4_unicode_ci，导致 MATCH() AGAINST() 内部比较行为不一致。

检查字段 collation：SHOW CREATE TABLE liju; 看 cn 列是否用了 utf8mb4_0900_as_cs；如果不是，ALTER TABLE liju MODIFY cn VARCHAR(255) COLLATE utf8mb4_0900_as_cs;
确认全文索引是否真的绑定了 ngram：SHOW INDEX FROM liju; 中 Comment 字段应含 parser "ngram"
避免在查询中混用不同 collation 的字段，例如 FIND_IN_SET() 或 JOIN 条件里字段 collation 不一致，会直接触发 ERROR 1267，全文查询根本跑不起来