MongoDB索引与WiredTiger缓存的关系解析

是的，索引数据当然会进入WiredTiger缓存——所有索引页，无论是B-tree的根页面（root page）、内部页面（internal page）还是叶子页面（leaf page），都由WiredTiger缓存统一管理。这里不存在“数据页”与“索引页”的区分，整个B-tree结构均按页面为单位加载进缓存。只要查询触发了索引扫描操作，对应的索引页就会被载入working_set工作集。

这意味着什么？索引并非仅仅躺在磁盘或操作系统页面缓存（OS Page Cache）中“睡大觉”；它必须先由WiredTiger从磁盘读取到自己的缓存中，才能参与后续的查找过程。如果索引体积过大而缓存空间太小，频繁的索引页换入换出将直接拖慢查询响应速度——这绝非危言耸听。

• wiredTigerCacheSizeGB这个配置项直接影响索引页在缓存中的驻留能力，但并非越大越好，需要结合工作集大小与系统内存总量来综合权衡。
• 复合索引的前导字段越常被查询，其对应路径上的内部/叶子页面就越容易保留在缓存中。
• 通过db.collection.stats()中的wiredTiger.cache.bytes currently in the cache字段，可以观测索引页的实际内存占用情况。

为什么加了索引，缓存命中率反而下降？

这个问题常见于索引膨胀场景：当你为高基数字段创建了大量单字段索引，或者忘记删除旧索引导致索引总数激增时，WiredTiger缓存就会被大量低频访问的索引页占据，从而把真正热点的数据页和常用索引页挤出去。

WiredTiger采用LRU-K算法淘汰页面，但K值固定为3，对“偶发大范围索引扫描”缺乏感知——一次带有explain("executionStats")且indexOnly: false的全索引扫描，可能瞬间就把一批活跃数据页刷出了缓存。

• 检查db.serverStatus().wiredTiger.cache["pages evicted by application thread"]是否异常偏高。
• 使用db.collection.getIndexes()识别冗余索引，尤其要留意createdCollectionAutomatically: true这类隐式创建的索引。
• 在写入密集型场景下，尽量避免频繁重建索引——db.collection.createIndex(..., { background: true })仍然会争抢缓存资源。

WiredTiger缓存和OS Page Cache怎么分工？

两者并非互斥关系，而是协同工作：WiredTiger缓存管理逻辑页面（解压后、携带事务版本的B-tree页面），OS Page Cache管理物理块（压缩后的原始文件块）。一次索引查找需要经过两层：先从OS Page Cache读取压缩的索引块，然后WiredTiger解压并解析成逻辑页面，再放入自己的缓存供后续复用。

因此，即使wiredTigerCacheSizeGB设置得很小，只要操作系统有足够的空闲内存，索引文件的底层块仍然可能留在Page Cache中，从而降低磁盘I/O。但WiredTiger缓存不足时，每次查询都需要重复解压、校验、构建逻辑页面，CPU和延迟代价会明显上升。

• 不要盲目关闭OS Page Cache（例如使用O_DIRECT），WiredTiger依赖它做底层块的预读操作。
• vm.swappiness=1比0更为稳妥，可以避免OOM Killer误杀mongod进程。
• 监控/proc/meminfo中的PageTables值，数值过高说明页表开销大，可能与索引碎片有关。

如何验证某个索引是否真正在缓存里生效？

不能只看explain()输出的indexOnly: true——那仅代表查询能够走索引覆盖，并不表示索引页当前就在WiredTiger缓存中。真正需要关注的是执行时的缓存行为。

最直接的方式：在查询前后对比缓存状态的实时变化。关键指标不是“用了索引”，而是“是否避免了从磁盘加载索引页”。

• 执行查询前记录下db.serverStatus().wiredTiger.cache["bytes read into cache"]的值。
• 执行查询后再次获取该值，差值接近0说明索引页已缓存；若增长明显（例如超过64KB），则说明发生了新页面加载。
• 配合db.setProfilingLevel(2)抓取慢查询，重点观察executionStats.nReturned与executionStats.totalDocsExamined是否接近——如果两者相差较大但缓存加载量很高，说明索引选择性差，缓存被无效页面污染。

说到底，WiredTiger缓存对索引的依赖是双向的：索引效率决定了缓存压力，而缓存容量又反过来约束了索引设计。最容易忽略的一点是——索引元数据本身也占用缓存空间。每个索引条目在内存中不仅仅是键值对，还包括指向数据页的指针、版本信息、锁结构等，这部分开销在高并发更新场景下会快速累积，需要格外留意。