MongoDB索引和缓存（WiredTiger Cache）的关系？

是的，索引数据进入WiredTiger缓存；所有索引页（root、internal、leaf）均以page为单位由WiredTiger统一缓存管理，不区分数据页与索引页，查询触发索引扫描即加载对应页至working_set。

索引数据是否进WiredTiger缓存？

是的，所有索引页（包括B-tree的root page、internal page和leaf page）都由WiredTiger缓存统一管理。WiredTiger不区分“数据页”和“索引页”，而是把整个B-tree结构按page为单位加载进缓存——只要查询触发了索引扫描，对应索引页就会被载入working_set。

这意味着：索引不是只存在磁盘或OS Page Cache里；它必须先被WiredTiger从磁盘读到自己的缓存中，才能参与查找。如果索引太大、缓存太小，频繁的索引页换入换出会直接拖慢查询响应。

• wiredTigerCacheSizeGB配置值直接影响索引页驻留能力，不是越大越好，需结合工作集大小与系统内存总量权衡
• 复合索引的前导字段越常被查询，其对应路径上的internal/leaf pages越容易保留在缓存中
• 使用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 page），OS Page Cache管物理块（压缩后的原始文件块）。一次索引查找要经过两层：先从OS Page Cache读取压缩的索引块 → WiredTiger解压并解析成逻辑页 → 放入自己的缓存供后续复用。

所以即使wiredTigerCacheSizeGB设得很小，只要OS有足够空闲内存，索引文件的底层块仍可能留在Page Cache里，降低磁盘IO；但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缓存对索引的依赖是双向的：索引效率决定缓存压力，缓存容量又反向约束索引设计。最容易被忽略的是索引元数据本身也占缓存空间——每个索引条目在内存中不只是键值，还包括指向数据页的指针、版本信息、锁结构等，这部分开销在高并发更新场景下会快速累积。