MySQL全文索引那些限制和坑，了解下别踩雷了

MySQL的全文索引是一个很有用的功能,它能让你对数据表中的文本内容进行关键词搜索，比传统的LIKE '%keyword%'语句效率高得多，尤其是在处理大量文本数据时，它并非万能，有很多特定的限制和容易让人栽跟头的地方。

最核心的限制：引擎与版本差异

这个是最基本的,但很多人会忽略，在MySQL 5.6版本之前，全文索引只支持MyISAM存储引擎，MyISAM不支持事务，在并发写操作频繁的场景下性能很差，表级锁很容易成为瓶颈，所以那时候用全文索引的人不多。

从MySQL 5.6版本开始，InnoDB引擎也支持了全文索引，这让它变得实用起来，但需要注意的是，不同版本（5.6, 5.7, 8.0）的InnoDB全文索引在底层实现、功能和性能上都有差异，查询的语法、分词的改进等在8.0版本中有了很大提升，讨论全文索引的“坑”，必须结合你使用的MySQL版本。

分词机制带来的主要“坑”

全文索引的核心是“分词”，也就是把一段文本拆分成一个个独立的词（Token）来进行索引和搜索，MySQL的分词方式决定了它的搜索行为，也带来了很多限制。

1. 停用词（Stopwords）问题：这是最常遇到的坑之一，MySQL内置了一个“停用词”列表，这些词通常是非常常见但被认为没有实际搜索意义的词，比如英文的“the”, “a”, “an”, “in”，中文的“的”、“是”、“在”等。全文索引会完全忽略这些停用词，既不会索引它们，也不会在搜索中匹配它们。

   

   • 坑点体现：如果你搜索“the house”，搜索结果是所有包含“house”的记录，而不管“the”是否存在，更坑的是，如果你搜索的内容全部由停用词组成，比如搜索“to be or not to be”，会直接报错，或者返回空结果。
   • 应对方法：你可以自定义停用词列表，比如创建一个空的停用词列表来禁用这个功能（但会导致索引体积变大），但这需要修改配置并重建索引。

2. 最小词长（ft_min_word_len）：为了避免索引太多无意义的短词（如英文的“I”, “be”），MySQL设置了最小词长限制，默认是4个字符，这意味着，长度小于4个字符的词不会被索引。

   • 坑点体现：你想搜索“CPU”或者“USA”这种三个字母的缩写，会发现根本搜不到，或者搜索“PHP是最好的语言”中的“PHP”，也会被忽略。
   • 应对方法：同样需要修改配置文件中的ft_min_word_len（MyISAM）或innodb_ft_min_token_size（InnoDB）参数，然后必须重建全文索引，否则修改不生效。

3. 对中文的支持非常不友好：这是中文用户的巨大痛点，MySQL默认的分词器是按空格和标点符号进行分词的，这对于英文等西文语言很有效，但中文句子没有空格分隔，MySQL默认会把一整段中文当成一个长长的“词”。

   • 坑点体现：比如一段文字“今天天气真好”，如果不使用第三方分词插件，MySQL会把它当成“今天天气真好”一个词来处理，你搜索“天气”是无法匹配到这条记录的，必须完全匹配“今天天气真好”才行，这完全失去了全文搜索的意义。
   • 应对方法：在MySQL 5.7及以上版本中，可以使用ngram分词插件来解决这个问题，ngram会按指定的长度（比如2，即二元分词）把文本切分，“今天天气真好”会被切成“、“天天”、“天气”、“气真”、“真好”等多个词，这样搜索“天气”就能匹配到了，但这也带来了索引体积增大和噪音词增多的问题。

查询语法和结果相关的问题

1. 布尔模式（IN BOOLEAN MODE）的复杂性：全文搜索支持自然语言模式和布尔模式，布尔模式功能强大，可以用（必须包含）、（必须不包含）、（通配符）等操作符，但很容易用错。

   

   • 坑点体现：布尔模式会忽略50%阈值（见下一条），但它的排序可能不符合直觉，使用通配符时，如果前缀词长度小于最小词长，通配符搜索会失效。
   • 应对方法：仔细阅读官方文档关于布尔搜索的说明，充分测试。

2. 50%阈值规则（仅限自然语言模式）：在自然语言搜索模式下，如果一个词在超过50%的记录中都出现了，MySQL会认为这个词是“太常见”的噪音词，从而在搜索结果中完全忽略这个词。

   • 坑点体现：假设你有一个文章表，其中有一个“状态”字段，大部分文章的状态都是“已发布”，如果你搜索“已发布的教程”，因为“已发布”这个词出现在了超过50%的行中，MySQL会直接忽略它，只搜索“教程”，结果会返回所有包含“教程”的文章，而不管其状态是否为“已发布”，这很可能不是你想要的。
   • 应对方法：换用IN BOOLEAN MODE进行搜索，布尔模式不受此规则限制。

性能和运维的坑

1. 索引维护成本：全文索引的维护（创建、重建）通常比普通B-Tree索引要慢得多，占用更多资源，因为它涉及复杂的分词过程，对于大表，创建全文索引可能会锁表很长时间（取决于版本和设置），影响线上服务。
2. 索引体积大：全文索引通常会比原始数据占用更多的磁盘空间，特别是使用了ngram分词器之后，空间消耗会成倍增长。
3. DML操作开销：对表进行INSERT、UPDATE、DELETE操作时，维护全文索引的代价比维护普通索引高，在高并发写入的场景下，可能会成为性能瓶颈。

总结建议：

在使用MySQL全文索引前,一定要先明确你的需求：

• 如果你的搜索需求简单,且数据量不大，LIKE可能就够了。
• 如果需要较好的中文搜索,务必使用MySQL 5.7+并配置ngram分词器。
• 如果对搜索相关性、功能有很高要求（如同义词、高亮、复杂排序），MySQL的全文索引可能力不从心，应考虑专业的搜索引擎，如Elasticsearch或Solr，它们才是为复杂的全文搜索场景而生的。

MySQL全文索引是一个“够用就好”的工具，了解它的这些“坑”和限制，能帮助你在合适的场景下正确地使用它，避免项目后期踩到难以解决的雷。