全文索引适用于长文本字段的关键词检索，需用match against语法，并注意配置与优化。1.适合场景：对文章内容、产品描述等大段文本进行关键词或多个词语组合查询，不依赖前缀匹配；2.建立要点：仅支持char、varchar、text类型字段，可建单列或多列组合索引，注意调整最小词长及使用ngram插件支持中文；3.优化策略：设置停用词减少冗余索引，使用布尔模式提升查询灵活性，控制返回结果数量并定期执行analyze table；4.注意事项：非match against查询无法触发全文索引，中文需额外配置，索引体积较大且不支持函数表达式。
MySQL的全文索引（Fulltext Index）在处理文本类数据检索时非常有用，尤其是在需要模糊匹配或关键词搜索的场景下。但很多人只是简单地加上了FULLTEXT索引，却忽略了它的一些限
制和优化技巧。这篇文章就从实际使用角度出发，讲讲什么时候适合用、怎么建、以及有哪些需要注意的地方。
全文索引主要适用于大段文本字段的查询需求，比如文章内容、产品描述、评论等。如果你经常需要对这类字段做类似“包含某个词”或者“多个关键词匹配”的查询，那全文索引会比LIKE '%xxx%'高效得多。
举个例子：你有一个博客系统，想根据用户输入的关键词查找相关文章内容。这时候就可以给content字段加上全文索引，然后使用MATCH AGAINST语句进行查询。
适用场景总结：
建立全文索引看起来很简单，就是加一个FULLTEXT关键字。但有几个细节容易被忽略：
支持的数据类型有限制
只能用于CHAR、VARCHAR、TEXT及其变种字段。
可以是单列，也可以是多列组合索引
比如你可以同时对标题和正文建立联合全文索引：
CREATE FULLTEXT INDEX idx_title_content ON articles(title, content);
注意最小/最大词长限制
MySQL默认不索引长度小于4个字符的词（innodb_ft_min_token_size），这对中文来说不太友好。如果要用中文分词，建议配合插件（如ngram）调整配置。
不要在频繁更新的字段上滥用
全文索引的维护成本比普通索引高，尤其在INSERT/UPDATE频繁的表上，会影响性能。
用了全文索引不代表就能立刻提升性能，还需要一些策略来让它更有效：
合理设置停用词
默认有些常见词（如“the”、“is”）不会被索引，这叫停用词（stopword）。如果你的应用场景中有大量无意义词汇，也可以自定义停用词列表，减少冗余索引。
结合布尔模式提高灵活性
使用IN BOOLEAN MODE可以让查询更灵活，比如强制包含某词、排除某词：
SELECT * FROM articles WHERE MATCH(content) AGAINST('+database -mysql' IN BOOLEAN MODE);适当控制返回结果数量
全文索引排序依据的是自然语言相关性（relevance score），如果不加LIMIT，可能会查出一堆低相关性的结果，影响效率。
定期做ANALYZE TABLE
对于InnoDB引擎来说，全文索引的统计信息不会实时更新，定期执行ANALYZE TABLE有助于优化器做出更好的选择。
虽然好用，但也有一些坑需要注意：
不是所有查询都能走全文索引
如果你写的是普通的WHERE条件，比如WHERE content LIKE '%mysql%'，是不会触发全文索引的，必须用MATCH AGAINST语法。
中文支持需要额外配置
默认的分词机制对中文不太友好，建议使用ngram插件来支持中文分词。否则很多情况下无法命中关键词。
索引文件体积较大
相比普通索引，全文索引占用的空间更大，特别是在大数据量表上，要提前评估存储开销。
不支持函数式表达式索引
MySQL目前还不支持对表达式建立全文索引，比如不能直接对UPPER(content)建索引，这点跟普通索引不同。
基本上就这些。全文索引是一个很有用的工具，但得用对地方，还得注意它的限制和优化方式。用好了能大幅提升文本类查询的效率，用不好反而拖慢性能。