key为NULL说明全文索引未生效，因MySQL全文索引要么走FTS_DOC_ID索引，要么全表扫描；常见原因包括误用LIKE、引擎不支持、字段不匹配、关键词过短等。
Navicat里执行计划中key为NULL，说明全文索引没生效
只要EXPLAIN结果里key列是NULL，基本可以断定全文索引（FULLTEXT）没被用上。MySQL不会像B-tree索引那样“退而求其次”走全表扫描还标个possible_keys——它要么明确走FTS_DOC_ID索引，要么直接type=ALL。常见原因包括：
• 查询用了LIKE '%word%'而非MATCH ... AGAINST
• 表引擎不是MyISAM或InnoDB（其他引擎不支持）
• MATCH字段和FULLTEXT索引定义的列不完全一致（比如多了一个空格、大小写不敏感但定义时指定了collation）
• 查询词长度低于ft_min_word_len（默认4），如搜“go”会被直接忽略
确认是否触发了MATCH...AGAINST的索引扫描
在Navicat中右键SQL → “解释”，重点看两处：
• type列是否为fulltext（不是range或ref）
• key列是否显示你的全文索引名，例如idx_title_fulltext
如果看到type=fulltext且key非空，再核对rows值：InnoDB全文索引的rows通常是估算文档数，远小于总行数才说明有效过滤。若rows接近表总记录数，大概率是关键词太常见（停用词）、或AGAINST用了布尔模式但没加+-限定符导致匹配过宽
MyISAM和InnoDB全文索引在执行计划里的表现差异
两者在EXPLAIN输出中行为不同，容易误判：
• MyISAM：type=fulltext出现即代表走了索引，key显示索引名，Extra可能带Using filesort（因排序不走索引）
• InnoDB：即使type=fulltext，也要看Extra是否含Using where; Using MRR——没有Using where意味着只靠倒排索引定位，未结合WHERE其他条件做二次过滤，实际IO可能仍高
• 共同陷阱：MATCH(title) AGAINST('database' IN NATURAL LANGUAGE MODE)在低频词下可能退化为type=ALL，换IN BOOLEAN MODE并加+强制包含可稳定触发索引
Navicat中验证全文索引是否覆盖查询路径
不要只信执行计划，要回溯索引定义本身：
• 在Navicat对象浏览器右键表 → “设计表” → “索引”页，确认索引类型是FULLTEXT，且字段名与MATCH中完全一致（包括顺序、是否含前缀长度）
• 若建的是组合全文索引（如FULLTEXT(title, content)），但查询只写MATCH(title) AGAINST(...)，MySQL 5.6+会用上，但5.5及更早版本要求MATCH字段顺序和索引定义严格一致
• 执行SHOW INDEX FROM your_table，检查Comment列是否为fulltext，Sub_part是否为NULL（非NULL表示只索引前N个字符，可能漏掉长词）
真正卡点往往不在执行计划本身，而在MATCH语法和索引定义之间那几处肉眼难辨的不匹配——比如字段名多了下划线、collation不一致、或InnoDB表没开innodb_ft_enable_stopword却误以为停用词导致失效。这些细节在Navicat的索引列表里都藏得挺深，得手动点开每一条核对。
