搜索引擎的索引到底是个什么数据结构——LSM树、倒排索引与B+树的协作真相

网上讲搜索引擎索引的文章，十篇里有九篇翻来覆去只讲倒排索引。搞得好像搜索引擎的整个索引系统就只是"词→文档ID列表"这一个映射表。实际远没这么简单。搜索引擎每天要处理的写入量是几百亿甚至上千亿级别的页面更新操作，同时还要保证毫秒级的查询响应。没有任何一种单一的数据结构能同时扛住这种写入和查询的双重压力。真相是，LSM树负责写入端的高吞吐、倒排索引负责查询端的快速命中、B+树负责元数据和辅助索引的有序管理，三套结构在底层精密协作。

先讲LSM树。为什么搜索引擎不直接把新抓到的页面实时更新到倒排索引里？因为倒排索引的随机写入性能差到不可接受——每插入一个文档就要更新十几个乃至几十个词条对应的倒排列表，这些更新分散在磁盘的不同位置，IO延迟叠加起来能把系统拖死。LSM树的存在就是为了解决这个问题。新数据先写进内存中的MemTable，攒到一定量之后整体刷到磁盘上形成不可变的SSTable文件。写入操作在内部被转化为纯顺序写，吞吐量直接拉满。搜索引擎的爬虫每分每秒往LSM树里疯狂灌入新页面的词-文档映射，而LSM树则在后台静默地执行Compaction操作，把零散的小SSTable合并为结构紧凑的大文件。你的页面从被爬取到参与搜索结果可见的过程，有很大一段延迟就消耗在这个Compaction的流水线里。

然后才是倒排索引。搜索引擎在收到查询请求的时候不是在LSM树上直接搜的，那太慢了。系统会维护一套和LSM树保持异步同步的倒排索引快照，查询走的是这个快照。倒排索引的核心数据结构其实不是很多人以为的简单链表，而是SkipList——跳表。跳表在每个倒排列表上叠加了多层跳跃指针，使得在合并多个查询词对应的倒排列表时可以跳过大量不相关的文档ID，将交集和并集的计算复杂度从O(N+M)压到接近对数级别。这就是为什么搜索引擎能在万亿级别的文档库中做到毫秒级返回结果。

B+树的角色容易被忽视，但同等重要。你的站点在搜索引擎的索引库里有一个对应的"站点级元数据记录"，包括最近一次爬取时间、站点权威值、收录页面总数、内容更新频率等维度。这些记录要求在范围查询时能高效遍历——比如"找出过去24小时内所有更新过内容的医疗类站点"——B+树在这种场景下是无可替代的。另外，链接关系图的大部分存储用的也是B+树变体。这就是为什么一个站被收录后如果长时间不更新，即使内容本身质量没变，排名也会慢慢下滑——B+树管理的站点新鲜度元数据在变旧。

在VP导航（vpis.cn）上提交站点，本身就是在触发这套庞大索引系统的一次元数据更新。了解这三层数据结构的协作方式，你就能理解为什么有些操作（比如改一个标题或者加一段Schema标记）在短时间内就能看到收录变化，而有些操作（比如大规模调整站内链接结构）需要数周才能判明效果——它们对应的是不同层级数据结构的更新延迟。