MySQL默认分词器不识别中文词，因其仅按空格/标点切分，将“我爱编程”视为整体而非“我”“爱”“编程”；ngram仅为固定长度子串切分，非真正语义分词，且仅支持自然语言模式，需显式配置token_size、WITH PARSER ngram并重启服务。
MySQL默认分词器根本不识别中文“词”
MySQL原生全文索引（无论MyISAM还是InnoDB）的分词逻辑只认空格、制表符和标点——它把"我爱编程"整个当做一个“词”，而不是拆成"我"、"爱"、"编程"。这导致：MATCH(content) AGAINST('编程' IN BOOLEAN MODE)永远匹配不到该字段，因为索引里压根没存"编程"这个token。
根本原因不是“不支持中文”，而是它压根没设计中文分词能力：没有词典、不理解语义、不做歧义消解（比如"南京市长江大桥"该切"南京市/长江/大桥"还是"南京/市长/江大桥"），连基础的字边界都依赖人工加空格。
ngram只是“暴力子串切分”，不是真正分词
MySQL 5.7.6+ 提供的ngram解析器，本质是滑动窗口截取固定长度字符组合。设ngram_token_size=2，"中国"会被拆成"中"、"国"、"中国"三个token；"人工智能"则生成"人工"、"智能"、"人工智"、"能"等一堆冗余甚至无意义片段。
这种切法带来几个硬伤：
-
BOOLEAN MODE默认不走ngram路径，必须显式配合IN NATURAL LANGUAGE MODE或配置ft_parser=ngram才生效 - 短词（如单字
"爱"）和长词（如"中华人民共和国"）无法统一覆盖，召回率严重失衡 - 停用词机制对ngram无效——
"的"被切成"的"仍会进索引，污染权重
InnoDB和MyISAM在中文场景下同样失效
有人误以为切换存储引擎能解决问题，但实际：
- InnoDB从5.6起支持全文索引，但分词逻辑与MyISAM完全一致，都依赖空格/标点
- InnoDB特有的
innodb_ft_min_token_size参数（替代MyISAM的ft_min_word_len）只能调小最小token长度，解决不了无空格切分问题 - 即使你手动给中文加空格（如
"我 爱 编 程"），也会破坏语义连贯性，且用户输入搜索词时不会带空格
所以别纠结引擎选型——只要用原生全文索引，中文就是残缺状态。
真正能用的方案只有两个方向
要么彻底绕开MySQL内置能力，要么接受它的妥协边界：
- 用
Elasticsearch或Solr做独立检索服务：自带IK、jieba等插件，支持同义词、拼音、模糊匹配，且能处理"python"搜出"Python"或"蟒蛇" - 在写入时预分词：用
jieba或HanLP离线分好词，把结果存进额外字段（如content_tokens），再对该字段建普通B+树索引或全文索引——但要自己维护分词一致性、停用词、更新延迟等问题
试图靠调整my.cnf里的ngram_token_size或ft_stopword_file让MySQL“变聪明”，只会浪费调试时间。中文检索的复杂度不在配置层面，而在语言学层面。
