mysql中match against查不到预期结果最常见原因是表引擎不支持或未建fulltext索引；字段类型需为char/varchar/text；中文需用ngram解析器或拼音预处理；自然语言模式有停用词和最短长度限制，布尔模式支持操作符但不返回有效相关性分数。
MySQL中MATCH AGAINST为什么查不到预期结果？
最常见原因是表引擎不是MyISAM或InnoDB（5.6+），且字段没建FULLTEXT索引。InnoDB支持MATCH AGAINST，但必须显式创建全文索引，不能靠主键或普通索引“自动生效”。
-
CREATE TABLE时未加FULLTEXT(title, content)，后续ALTER TABLE补索引也行，但数据量大时会锁表较久 - 字段类型必须是
CHAR、VARCHAR或TEXT；INT或JSON列直接MATCH会报错ERROR 1191: Can't find FULLTEXT index matching the column list - 中文需额外处理：MySQL原生全文索引对中文不友好，因为默认按空格/标点分词，而中文无天然分隔符——这不是
MATCH AGAINST写法问题，是底层分词机制限制
自然语言模式 vs 布尔模式：该用哪个？
自然语言模式（默认）适合用户输入的普通搜索语句，比如“苹果手机续航”，MySQL自动计算相关性并按score排序；布尔模式则支持+、-、*等操作符，适合后台管理搜索。
- 自然语言模式下，停用词（如“的”、“和”、“在”）会被忽略，且单个词长度低于
ft_min_word_len（默认4）也不索引 → 搜“AI”可能无结果，因长度为2 - 布尔模式可绕过停用词和最小长度限制：
MATCH(title) AGAINST('+AI<em>' IN BOOLEAN MODE)</em>，但只支持后缀匹配，不支持中间通配 - 相关性分数在自然语言模式下才有意义；布尔模式返回的
score恒为1，仅作是否存在判断
如何让中文也能用MATCH AGAINST有效检索？
纯MySQL不做插件或改造时，可行路径只有两个：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 把中文转成带空格的拼音或分词结果存入额外字段，再对该字段建
FULLTEXT索引。例如用Python预处理“微信”→“wei xin”，“支付宝”→“zhi fu bao”，然后MATCH(pinyin_title) AGAINST('zhi fu' IN NATURAL LANGUAGE MODE) - 改用
ngram全文解析器（MySQL 5.7.6+）：CREATE FULLTEXT INDEX ft_content ON articles(content) WITH PARSER ngram，并设置ngram_token_size=2，这样“支付宝”会被切为“支 付 宝 支付 付宝”，支持2字起搜 - 注意：
ngram不支持布尔模式里的+/-，且AGAINST中的搜索词也会被同样切分，搜“支付”实际变成搜“支付”+“付”两个token
为什么EXPLAIN显示type=ALL，MATCH还是很快？
因为MATCH AGAINST走的是全文索引B+树的特殊遍历路径，不依赖传统key字段的等值查找逻辑。EXPLAIN无法准确反映其执行方式，看到type=ALL别慌。
- 真实性能瓶颈往往在分词和相关性计算，尤其自然语言模式下长文本+多字段
MATCH时CPU占用明显升高 - 若查询带
WHERE其他条件（如status = 1），务必把MATCH条件和过滤条件合并进同一WHERE子句，避免先全表扫描再过滤 - 多字段
MATCH必须所有字段都在同一个FULLTEXT索引里，跨索引字段无法联合评分
全文索引不是万能的，特别是中文场景下，ngram的粒度、停用词策略、以及预处理成本，都得根据实际数据分布去试；盲目套用MATCH AGAINST反而比LIKE '%关键词%'更慢。
