MySQL 5.7 中文全文检索必须用 FULLTEXT + ngram 解析器，因原生索引按空格切词无法处理中文；需配置 ngram_token_size=2/3、ft_min_word_len=1，重启生效并 REPAIR 表，联合索引须显式声明 WITH PARSER ngram，MATCH 字段顺序须与索引一致。
MySQL 5.7 对 TEXT 字段做模糊查询，直接用 LIKE '%关键词%' 几乎必然慢到不可用——这不是写法问题，是底层不走索引。必须用 FULLTEXT + ngram 解析器，否则查几万行就卡死。
为什么 MATCH() AGAINST() 必须配 ngram 才能搜中文
MySQL 原生全文索引按空格/标点切词，对“人工智能发展快”这种中文串会当成一个超长词存进去。结果就是：搜“智能”，AGAINST('智能') 匹配不到任何记录。
ngram 是 MySQL 5.7 内置的滑动窗口分词器，它不管语义，只按固定长度切字。比如 ngram_token_size=2 时，“人工智能”会被拆成：“人工”、“智能”、“能发”、“发展”、“展快”。只要用户搜“智能”，就能命中。
- 不改配置直接建
FULLTEXT索引，ngram不生效，还是搜不到中文 -
ngram_token_size设为1虽然最细（每个字都单独成词），但索引体积暴增、写入变慢，生产环境建议用2或3 - 必须重启
mysqld才能让ngram_token_size配置生效，光 reload 不行
ft_min_word_len=1 不设就搜不到单字词
MySQL 默认 ft_min_word_len=4，意味着只给 4 字及以上的词建倒排索引。中文里“的”“是”“我”“爱”全是高频单字，不改这个值，AGAINST('爱') 永远返回空。
修改方式是在 /etc/my.cnf 的 [mysqld] 段落下加：
ft_min_word_len=1
改完必须执行 REPAIR TABLE tbl_article_content QUICK，否则旧数据不会被重新分词入库。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 改完配置不
REPAIR，新索引只对后续 INSERT 生效，历史数据查不到 -
REPAIR期间表会被锁，大数据量需安排低峰期操作 - 该变量不能动态 SET，必须改配置文件 + 重启
多字段联合全文索引要显式声明 WITH PARSER ngram
如果想同时搜标题和内容，得建联合全文索引，而不是分别建两个单字段索引。否则 MATCH(title, content) AGAINST(...) 会报错或降级为自然语言模式失效。
正确写法是：
ALTER TABLE tbl_article_content ADD FULLTEXT INDEX ft_title_content (title, content) WITH PARSER ngram;
注意：WITH PARSER ngram 必须写在最后，漏掉就等于没开中文分词。
- 建表时定义的索引，语法里也要带
WITH PARSER ngram，不能只依赖配置 -
MATCH()里字段顺序必须和索引定义顺序一致，MATCH(content, title)会失败 - 布尔模式搜索（如
AGAINST('+编程 -算法' IN BOOLEAN MODE)）也依赖ngram分词，否则符号无效
查询结果相关性排序不是默认行为
MATCH() AGAINST() 默认返回的是布尔匹配（有/无），不是按匹配度排序。如果想让“包含关键词最多”的文章排前面，得显式 SELECT 相关性得分：
SELECT id, title, MATCH(content) AGAINST('数据库优化') AS score FROM tbl_article_content WHERE MATCH(content) AGAINST('数据库优化') ORDER BY score DESC;这个 score 是 MySQL 内部计算的浮点数，值越大越相关。但要注意：
- 同一查询多次执行，
score可能浮动，不建议用于精确排序逻辑 - 如果字段含大量停用词（如“的”“了”“在”），得分会被拉低，
ngram本身不内置停用词表 - 想稳定排序，得自己加权重逻辑，比如给标题字段更高匹配系数
真正难的不是建索引，而是确认每条数据是否真的被 ngram 正确切分进了倒排索引——最保险的方式是用 SELECT * FROM information_schema.INNODB_FT_INDEX_TABLE WHERE WORD = '你查的词'; 直接查索引表。别只信 SHOW CREATE TABLE。
