MySQL 5.7 的表里如果存了大量文章、日志或评论内容，用 LIKE '%关键词%' 做模糊查询会变成全表扫描。数据量一大，查询延迟会从几十毫秒变成几秒，甚至拖垮数据库连接池。要解决这个问题，MySQL 5.7 提供了一个更合适的方案：使用内置的 NGRAM 全文解析器建立全文索引，再用 MATCH ... AGAINST 函数完成检索。它并不等同于任意子串匹配，但在中文场景下可以覆盖大多数模糊查询需求，同时让查询性能有数量级的提升。
接下来先分析 LIKE 模糊查询的性能瓶颈，再说明 NGRAM 的工作机制、配置方法以及实际落地时的注意事项。
一、LIKE 模糊查询的性能瓶颈
在关系型数据库中，普通 B+ 树索引只能利用前缀有序的特性。一旦使用 LIKE '%keyword%'，查询条件以通配符开头，优化器无法确定扫描范围，只能逐行读取大字段并做字符串比对。这种执行计划通常显示为全表扫描，即使 keyword 上有普通索引也不会被使用。
更糟的是，文本字段通常较大，可能包含几 KB 甚至几 MB 的内容。全表扫描不仅要访问主键聚簇索引中的行数据，还要把大对象从磁盘读到内存，导致大量随机 IO 和缓冲池污染。随着行数增长，成本线性上升。对一张 100 万行的文章表执行这种模糊查询，查询耗时超过 5 秒并不少见，而同样条件下如果走全文索引，可以控制在几十毫秒量级。
EXPLAIN SELECT id, title FROM articles WHERE content LIKE '%数据库索引%';
执行计划通常会显示 type=ALL、rows 接近总行数，说明索引失效。这类查询在高并发下会给数据库带来极大压力，因此需要引入适合文本内容搜索的索引结构。
二、NGRAM 全文解析器的工作机制
NGRAM 是一种基于固定长度切分的文本解析器。它不依赖空格或标点识别词语，而是把整段文本按 N 个字符为一个单元连续切分。默认的 ngram_token_size 为 2，例如字符串「数据库索引」会被切成「数据」「据库」「库索」「索引」四个词元。对中文来说，这种切分方式不需要额外词典，实现简单、召回率较高。
在创建全文索引时，NGRAM 解析器会先对字段内容进行切分，再为每个词元建立倒排索引，记录包含该词元的文档 ID 和位置。查询时，MATCH ... AGAINST 会对搜索词执行同样的解析流程，然后通过倒排索引快速命中候选文档。相比 LIKE 的逐行比对，这种方式把查询复杂度从 O(N) 降到了接近 O(log N) 或基于倒排列表的匹配成本。
输入文本：大文本字段模糊查询 默认 NGRAM 切分：大文、文本、本字、字段、段模、模糊、糊查、查询
不过，NGRAM 不是真正的子串匹配。它可能把「模糊查询」拆成「模糊」「糊查」「查询」三个词元，然后对包含这些词元的文档做匹配。如果不对词序做约束，可能出现正文包含「模糊」和「查询」但并非连续出现却被命中的情况。可以通过布尔模式中的短语搜索来缓解，这在后面会说明。
三、启用并配置 NGRAM 解析器
MySQL 5.7 默认已编译支持 NGRAM，不需要安装额外插件。默认的 ngram_token_size 是 2，适合大多数中文检索场景。如果业务上主要搜索三字词或四字词，可以将该值调大，减少切分后的词元数量，从而降低索引体积并提高精确度；但调大后会降低对短词的召回能力，比如搜索「查询」时可能无法命中。
修改该参数需要编辑 MySQL 配置文件。以 Linux 环境为例，可以在 my.cnf 的 [mysqld] 段落中加入：
[mysqld] ngram_token_size=2
保存后重启 MySQL 服务才会生效。注意该参数只影响参数生效之后新建的全文索引。如果之前已经用默认值建过 NGRAM 索引，需要删除并重建，否则索引内部的分词粒度仍然是旧值。
四、创建全文索引并使用 MATCH AGAINST 查询
假设有一张 articles 表，包含 id、title 和 content 字段，可以在 content 上创建 NGRAM 全文索引：
ALTER TABLE articles ADD FULLTEXT INDEX ft_articles_content (content) WITH PARSER ngram;
创建索引后，就可以使用 MATCH ... AGAINST 函数进行检索。自然语言模式会返回相关度排序的结果：
SELECT id, title, content
FROM articles
WHERE MATCH(content) AGAINST('数据库索引' IN NATURAL LANGUAGE MODE)
LIMIT 20;这种写法可以替代 LIKE '%数据库索引%'，并且能够利用全文索引。对于需要控制词序或包含逻辑的场景，建议使用布尔模式。例如，要求结果中必须包含「数据库」，并且最好包含「索引」，可以写：
SELECT id, title
FROM articles
WHERE MATCH(content) AGAINST('+数据库 索引' IN BOOLEAN MODE)
LIMIT 20;布尔模式中还支持短语搜索。如果希望匹配连续的「数据库索引」，可以在搜索词外使用英文双引号：
SELECT id, title
FROM articles
WHERE MATCH(content) AGAINST('"数据库索引"' IN BOOLEAN MODE)
LIMIT 20;需要注意 SQL 语句中字符串外层使用单引号，短语内部使用双引号不会产生冲突。这种方式下 NGRAM 会利用词元位置信息判断词序，从而降低误匹配。
五、性能对比与生产环境注意事项
与 LIKE 全表扫描相比，NGRAM 全文索引在数据量增长时能保持较低的查询延迟。实测中，百万级文章表上执行 MATCH ... AGAINST 查询通常可以在几十毫秒返回，而等效的 LIKE 查询往往需要几秒。原因在于全文索引只读取包含相关词元的倒排列表，不需要扫描无关行的大字段。
但 NGRAM 也有代价。首先是索引体积：默认按两个字符切分，会让一个中文文本产生大量词元，索引文件可能比原表还大。其次，写入成本上升，每次插入或更新内容时都要重新切分并更新倒排索引，批量导入时速度会受明显影响。另外，NGRAM 不适合极短的单字搜索，默认 token 为 2，单个汉字无法被有效索引。
如果业务对模糊查询的精度要求很高，例如必须支持任意位置的子串匹配，可以结合应用层搜索引擎或使用 MySQL 之外的方案。但对于大多数中文内容平台、日志检索和文章搜索场景，NGRAM 全文索引是用 SQL 函数解决大文本字段模糊查询的成熟手段，部署成本低，易于维护。
MySQL 5.7NGRAM全文解析器大文本模糊查询修改时间：2026-09-21 22:10:41