MySQL 5.7 InnoDB全文索引无内置命中率统计，所谓“命中率低”实为分词失败、模式不当或数据特征不匹配所致；中文需启用ngram插件并合理设置token_size，推荐使用布尔模式提升可控性，并结合结构化条件过滤以优化性能。
MySQL 5.7 中 InnoDB 全文索引本身不提供“命中率”指标，所谓“检索命中率低”，本质是 MATCH() AGAINST() 返回结果少或不相关——问题出在分词、查询模式、索引覆盖或数据特征上，而非缓存或统计偏差。
为什么 SHOW STATUS 看不到全文索引命中率
不同于 Innodb_buffer_pool_read_requests 这类可计算的缓存指标，InnoDB 全文索引没有内置的“匹配成功次数 / 总查询次数”统计项。MySQL 不记录“用户搜了什么、匹配了几行、是否期望更多”。你看到的“命中少”，其实是业务侧反馈：关键词搜不到预期记录。
- 全文索引底层依赖倒排表 + 分词器，若词未被切分（如中文单字、短于
ft_min_word_len）、或被停用词过滤，就根本不会进索引 -
MATCH() AGAINST()在NATURAL LANGUAGE MODE下会按相关性排序并自动过滤低分结果（默认相关性阈值 ≈ 0），导致部分弱匹配行被静默丢弃 - 执行计划里看不到“全文扫描用了多少词”，
EXPLAIN对 FULLTEXT 查询仅显示type: fulltext，无法定位分词失败点
中文检索必须配 ngram 且设对 token_size
MySQL 原生不支持中文分词，5.7 默认用空格/标点切分，对连续汉字无效。不启用 ngram 插件，'数据库优化' 会被当做一个不可拆的长词，而你的索引里只有单字或根本没建索引。
- 确认插件已加载：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'ngram'; - 建索引时显式指定解析器：
ALTER TABLE articles ADD FULLTEXT(title, content) WITH PARSER ngram; - 设置分词长度：
SET GLOBAL ngram_token_size = 2;（支持“数 据”“据 库”“库 优”等两字组合；设为 1 效果差，设为 3 会漏掉大量双音节词） - 注意：
ngram_token_size是全局变量，修改后需重建全文索引才生效
布尔模式（BOOLEAN MODE）比自然语言模式更可控
NATURAL LANGUAGE MODE 会做隐式相关性计算和阈值过滤，同一词在不同行可能因字段长度、重复次数被压低分值，导致“搜得到但排太靠后被截断”。换成布尔模式，你能明确控制哪些词必须出现、哪些禁止、哪些可选。
- 强制包含“mysql”且排除“面试”：
MATCH(title,content) AGAINST('+mysql -面试' IN BOOLEAN MODE) - 支持通配符（需在末尾）：
AGAINST('optim*' IN BOOLEAN MODE)匹配 optimize / optimization - 短词可用引号保全：
AGAINST('"c++"' IN BOOLEAN MODE)避免被+符号干扰 - 注意：布尔模式下
ft_min_word_len仍生效，若设为 4，'sql'就不会被索引，加引号也无效
联合 WHERE 条件提前过滤，别只靠全文扫描
全文索引适合解决“文本内容模糊匹配”，但不适合替代结构化条件。比如查“2025 年发布的 MySQL 教程”，如果把年份、分类都塞进 content 字段再全文搜，效率低且易误匹配。应拆解为：
- 用普通 B-Tree 索引加速结构化字段：
CREATE INDEX idx_year_type ON articles(publish_year, category); - WHERE 先筛年份和类型：
WHERE publish_year = 2025 AND category = 'tutorial' - 再叠加全文条件：
AND MATCH(title, content) AGAINST('mysql' IN BOOLEAN MODE) - 这样能大幅减少参与全文匹配的行数，提升响应速度，也避免因全文扫描范围过大导致相关性失真
真正容易被忽略的是：全文索引不是“开了就灵”的黑盒。它高度依赖你对业务文本特征的理解——中文要 ngram、英文要注意停用词和词干、技术文档常含代码片段需调整 ft_min_word_len。每次改参数或换模式，都得用真实语料验证结果，而不是只看 SQL 是否报错。
