源码模糊查询底层原理？

访客源码剖析 2026-06-07 19:09:47 1

从索引结构到性能优化的深度解析

目录导读

模糊查询为何“慢”？——问题的本质
核心底层数据结构：B+树与倒排索引
LIKE查询的物理执行过程揭秘
百万级数据下的查询优化实践
常见模糊查询场景的选型对比
问答环节：高频面试题与避坑指南

模糊查询为何“慢”？——问题的本质

在数据库（如MySQL）中，SELECT * FROM users WHERE name LIKE '%张三' 这类查询往往让人头疼。本质原因在于：模糊查询破坏了索引的有序性。

全表扫描的代价：对于前缀模糊查询（如%keyword），B+树索引无法利用叶子节点的有序链表进行范围检索,只能逐行扫描。
索引失效的触发条件：当模糊匹配的通配符位于字符串左侧时，数据库优化器判断无法通过索引快速定位,转而选择全表扫描。

关键认知：模糊查询的“慢”并非数据库引擎不擅长,而是索引结构的设计天然不支持前缀模糊匹配的有效剪枝。

核心底层数据结构：B+树与倒排索引

1 B+树：InnoDB的默认索引结构

结构特性：内部节点仅存储键值指针，叶子节点存储完整数据记录（聚簇索引）或主键引用（二级索引）。
查询流程：对于LIKE 'abc%'（后缀模糊），数据库可沿B+树根节点向下二分查找，快速定位到前缀为“abc”的起始叶子节点,再通过链表顺序扫描。
索引失效点：当查询变为'%abc%'时，B+树无法判断中间节点的匹配起点,只能全局遍历。

2 倒排索引：全文搜索引擎的解决方案

原理：将文本分词后建立“词语→文档ID列表”的映射关系（如Elasticsearch的Lucene）。
模糊查询支持：通过有限状态机（FST） 或NGram分词，例如查询“张”时，直接定位所有包含该单字的文档ID,再合并求交集。
性能对比：在10万条数据中，B+树LIKE '%keyword%'耗时约300ms，而倒排索引仅需5ms（此数据基于特定测试环境，供参考）。

LIKE查询的物理执行过程揭秘

1 MySQL InnoDB的查询执行计划

EXPLAIN SELECT * FROM users WHERE name LIKE '%keyword%';
-- 输出 type = ALL （全表扫描）
-- 输出 rows = 100000 （扫描行数等于总行数）

2 物理过程逐步分解

解析与优化：SQL解析器处理LIKE操作，优化器评估索引（如idx_name）的使用代价,若在左侧则判定索引无效。
全表扫描启动：从聚簇索引的第一个数据页开始，逐页读取至最后一个页,每页内逐行检查。
字符匹配计算：每行数据的name字段通过CPU进行字符串匹配（如memcmp或自定义字符比较函数），若字段是变长类型（VARCHAR）,还需先解析长度前缀。
结果集构建：匹配成功的行通过缓冲池（Buffer Pool）的临时工作区缓存,最终返回给客户端。

性能瓶颈：磁盘I/O与CPU字符串比较的乘积效应——100万行数据需比较100万次字符串,且可能读取数千个数据页。

百万级数据下的查询优化实践

1 场景化优化方案

场景类型	推荐方法	实现原理
前缀模糊（`keyword%`）	建立普通B+树索引	利用B+树有序性快速定位起点
后缀模糊（`%keyword`）	反向索引存储（如存储`REVERSE(name)`）	将后缀问题转化为前缀问题
任意位置模糊（`%keyword%`）	Elasticsearch全文索引	基于倒排索引+NGram分词
少量数据（<10万行）	使用`INSTR`函数替代`LIKE`	避免正则回溯带来的性能开销（MySQL中INSTR有优化）

2 实操技巧（以MySQL为例）

索引列使用冗余字段：如name_rev VARCHAR(255)存储倒序字符串，对name_rev建立索引，查询改写为WHERE name_rev LIKE REVERSE('keyword%')
强制指定索引：SELECT * FROM users FORCE INDEX (idx_name) WHERE name LIKE 'keyword%'（仅适用于前缀模糊场景）
覆盖索引技术：只查询索引列（SELECT name FROM users WHERE name LIKE '%keyword%'）,减少回表开销。

常见模糊查询场景的选型对比

查询模式	推荐数据库	索引类型	适用数据量	性能参考（100万行）
精确前缀（`abc%`）	MySQL	B+树普通索引	千万级	<10ms
固定后缀（`%abc`）	MySQL+反向字段	B+树	百万级	<50ms
任意位置（`%abc%`）	Elasticsearch	倒排索引+NGram	亿级	<100ms
模糊匹配+排序	PostgreSQL	GIN（广义倒排索引）	千万级	<200ms

问答环节：高频面试题与避坑指南

Q1：为什么`LIKE '%keyword%'`有时比`LIKE 'keyword%'`慢100倍？

核心区别：前者必须全表扫描（或全索引扫描），后者可利用B+树快速定位到精确前缀范围，理论上，后者的时间复杂度是O(log n) + 线性扫描，而前者是O(n)全部遍历。

Q2：Elasticsearch的模糊查询为什么快？

技术实现：ES使用倒排索引，每个词对应一个文档ID列表，查询keyword时，直接通过字典树（Trie）或FST匹配所有包含该词或接近该词的文档ID，然后对ID列表做位运算合并，速度与词典大小相关,与文档总数无直接关系。

Q3：直接修改MySQL的`@like_range`变量能提升性能吗？

陷阱：range_optimizer_max_mem_size等参数影响的是范围查询优化器的内存使用，但%keyword%本身被归为“全表扫描”而非“范围查询”，因此修改该参数无效,真正的优化应聚焦于索引重构或使用全文搜索引擎。

Q4：生产环境中，如何快速定位模糊查询的性能瓶颈？

诊断步骤：

执行EXPLAIN分析是否命中索引（type列是否为range或ref）。
检查profiling：SET profiling=1; SELECT * FROM users WHERE name LIKE '%keyword%'; SHOW PROFILE;观察data locking、sending data阶段的耗时。
检查Handler_read_rnd_next状态变量：若其值等于行数,说明全表扫描。

模糊查询的底层原理归结为“索引结构与查询模式的匹配冲突”，理解B+树的前缀局限性、掌握倒排索引的逆向思维，是优化这类查询的关键，实际开发中，数据量小于10万行可直接使用LIKE，超出后应优先考虑Elasticsearch或PostgreSQL的GIN索引，切勿盲目增加MySQL索引数量——不当的索引反而会拖慢写入性能。