MySQL全文索引失效：五大硬门槛与精准排查指南
给MySQL表加上全文索引，却发现查询纹丝不动？这恐怕是不少开发者踩过的坑。真相是，全文索引并非“即插即用”的万能钥匙，它的生效与否，严格受制于存储引擎、字符集、最小词长、停用词表、查询语法这五道硬性门槛。跨不过其中任何一道，索引都可能直接“躺平”，让你的优化努力白费。
MyISAM全文索引能用但InnoDB不生效？先看存储引擎限制
存储引擎是全文索引的第一道分水岭。MyISAM引擎原生支持FULLTEXT索引，而且对停用词、最小词长的处理相对宽松。但如今更常用的InnoDB引擎，直到5.6版本才开始支持全文索引，并且默认行为严格得多。很多项目从MyISAM迁移到InnoDB后，全文搜索功能就“静默失效”了，原因往往在此。
- 确认表引擎：执行
SHOW CREATE TABLE table_name，仔细检查是否为ENGINE=InnoDB。 - 注意列类型与字符集：InnoDB的全文索引仅支持
VARCHAR、TEXT列，并且字符集必须是utf8mb4或latin1这类支持分词的类型。这里有个细节：utf8在MySQL 8.0+中已被视为utf8mb3的别名，它可能无法正确分词某些字符（比如emoji）。 - 警惕隐式忽略：MyISAM允许在
CHAR列上建立全文索引，但InnoDB不允许。如果你在建表语句中写了FULLTEXT(col)而col是CHAR(20)，InnoDB会直接忽略这个索引定义，在SHOW INDEX的结果里根本看不到它。
EXPLAIN显示type=ALL、key=NULL？重点查分词配置
如果EXPLAIN计划显示全表扫描，索引没被使用，问题很可能出在分词环节。InnoDB的全文索引基于倒排索引实现，本质是词项检索，而非简单的模糊匹配。如果查询词在分词阶段就被过滤掉了，引擎自然“无词可查”。
- 检查最小词长：执行
SELECT @@innodb_ft_min_token_size;（默认是3）。这意味着像'go'或'a'这样的短词，在查询时会被直接丢弃，结果就是查不到任何数据，而且系统不会报错。 - 查看停用词表：执行
SELECT @@innodb_ft_server_stopword_table;。默认情况下，系统会启用内置停用词表，像'the'、'and'、'is'这类高频但无实际检索意义的词会被自动跳过。 - 如何临时绕过停用词：对于需要检索停用词的场景，可以在建表时指定一个空的停用词表：
SET GLOBAL innodb_ft_server_stopword_table='';（需要SUPER权限）。另一种方案是建表时显式设置WITH PARSER ngram并配置ngram_token_size，利用N-gram解析器来规避默认的停用词规则。
MATCH() AGAINST()返回空？语法和字段必须完全对齐
全文搜索的查询语法相当严格，MATCH ... AGAINST ... 不是可以随意拼接的WHERE条件。MATCH子句中字段的顺序、数量、甚至名称，都必须与创建FULLTEXT索引时的定义保持完全一致。
- 字段数不匹配：索引建在
(title, content)上，查询却只写MATCH(title) AGAINST(...)→ 索引失效。 - 字段名不一致：索引建在
content上，查询写成MATCH(`content `) AGAINST(...)（字段名后多了一个空格）→ 索引失效。 - 模式声明错误：想使用布尔搜索的高级操作符（如
+,-），却漏写了IN BOOLEAN MODE。默认的自然语言模式对短词和停用词更敏感，且不支持这些操作符。 - 短语匹配的误区：在自然语言模式下，
AGAINST('mysql tutorial')会被拆分成“mysql”和“tutorial”两个独立的词进行搜索并计算相关性权重，这并非精确的短语匹配。要实现精确短语匹配，必须使用布尔模式：AGAINST('+mysql +tutorial' IN BOOLEAN MODE)。
为什么ANALYZE TABLE后还是不走全文索引？
有时候，即使执行了 ANALYZE TABLE，全文索引依然没有反应。这是因为InnoDB的全文索引依赖一系列内部的辅助表（命名类似 FTS_0000000000000123_0000000000000123_INDEX_1），这些表的统计数据不会通过常规的 ANALYZE TABLE 来更新。真正有效的方法是直接针对全文索引进行优化或重建。
- 强制刷新全文索引缓存：首先，执行
SET GLOBAL innodb_optimize_fulltext_only=ON;告诉InnoDB接下来只优化全文索引。然后，再执行OPTIMIZE TABLE table_name;。 - 更彻底的办法：重建索引：如果上述方法无效，可以考虑删除并重建全文索引：
ALTER TABLE table_name DROP INDEX ft_idx_name;然后ALTER TABLE table_name ADD FULLTEXT INDEX ft_idx_name (col1, col2);。 - 注意锁表风险：重建全文索引的过程涉及内部辅助表的操作，虽然InnoDB是行级锁，但在此期间DML操作仍可能被阻塞。对于线上核心大表，务必谨慎评估操作时机。
最后，必须认清全文索引的一个根本性限制：它并非为“左模糊”或“任意位置匹配”而设计。即便使用了 IN BOOLEAN MODE，其通配符 * 也仅支持词尾匹配（例如 search*），绝不支持 *arch 或 *earc* 这类模式。如果你的业务强依赖此类模糊查询，与其硬扛全文索引，不如考虑其他方案：简单的 LIKE '%...%' 配合合适的覆盖索引，或者，将搜索需求迁移到 Elasticsearch 这类专业的搜索引擎中，或许是更明智的选择。
