mysql全文索引在myisam和innodb中行为差异大：默认最小词长为3，导致短词被忽略；需重启修改参数并重建索引；布尔模式支持+/-/*/短语匹配；中文需应用层分词或换es；相关性得分仅用于同查询内排序。
MySQL全文索引只支持MyISAM和InnoDB，但行为差异很大
MySQL的FULLTEXT索引在MyISAM和InnoDB引擎下都可用，但默认分词逻辑、停用词处理、最小词长限制完全不同。InnoDB从5.6开始支持，但默认ft_min_word_len是3（MyISAM默认也是3），这意味着“go”“ai”“os”这类2字符词直接被忽略——这是站内搜索搜不到短关键词的最常见原因。
实操建议：
- 确认引擎：
SHOW CREATE TABLE your_table;看是否为InnoDB或MyISAM - 查当前最小词长：
SELECT @@ft_min_word_len;（InnoDB）或SELECT @@ft_min_word_len, @@ft_stopword_file;（MyISAM） - 修改InnoDB最小词长需重启MySQL，并设
innodb_ft_min_token_size=2；MyISAM则改ft_min_word_len=2并重启 - 重建索引：改完参数后必须
ALTER TABLE your_table DROP INDEX ft_idx, ADD FULLTEXT ft_idx (title, content);
自然语言模式 vs 布尔模式：别用错查询方式
MATCH() ... AGAINST()支持两种模式，默认是自然语言模式（IN NATURAL LANGUAGE MODE），它按相关性排序，但不支持通配符、+/-操作符，且对单个词无意义——比如AGAINST('mysql')可能返回一堆低相关结果，因为没指定匹配逻辑。
布尔模式（IN BOOLEAN MODE）才是站内搜索的实际选择，它允许精确控制：
-
+表示必须包含（+'mysql'） -
-表示必须排除（-'tutorial'） -
*是截断通配符（'myq*'匹配mysql,myql） - 双引号表示短语匹配（
'"database optimization"'） - 注意：
+和-后面不能有空格，否则失效
示例：SELECT * FROM posts WHERE MATCH(title, content) AGAINST('+\"full text\" +mysql -video' IN BOOLEAN MODE);
中文需要额外处理，MySQL原生不支持中文分词
MySQL的FULLTEXT索引按空白和标点切词，对中文完全无效——'数据库优化'会被当做一个长达12字的“词”，而你的索引里根本没有这么长的词条，所以永远查不到。
可行方案只有两个：
- 应用层分词：插入前用jieba、ansj等工具把
content字段拆成空格分隔的词（如'数据库 优化 mysql 性能'），再存入MySQL；查询时也对用户输入做同样分词，拼成布尔查询字符串 - 换搜索引擎：Elasticsearch或Meilisearch天然支持中文，且提供拼音、同义词、纠错能力，MySQL全文索引只适合英文或日文（假名可空格分隔）场景
- 硬编码绕过（不推荐）：用
LIKE '%关键词%'配合ORDER BY手工算权重，但数据量一过10万行就明显变慢
相关性评分RELEVANCE不是绝对值，且无法直接用于排序以外用途
MATCH() ... AGAINST()返回的浮点数只是内部计算出的相对得分，不同表、不同字段长度、不同停用词列表下完全不可比。你不能把它存为“搜索热度”或拿去加权计算，也不能假设2.4 > 1.9就代表前者更“准确”——它只保证在同一查询中排序有效。
容易踩的坑：
- 在
SELECT里多次写MATCH() ... AGAINST()会重复计算，拖慢性能；应只写一次，用别名引用：SELECT *, MATCH(title) AGAINST('abc') AS score FROM t ORDER BY score DESC - 没有
WHERE条件时，MATCH()返回0，但0仍参与排序，可能把不匹配的行排在前面 - InnoDB中，若查询词在全文索引中出现频率超过30%，该词会被视为“停用词”，得分强制为0（类似Google的“stop word”机制）
真正上线前，务必用真实数据跑一遍EXPLAIN看是否命中type: fulltext，而不是退化成ALL扫描——那是索引根本没生效的信号。
