是的，索引数据进入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是否接近——若相差大但缓存加载量高，说明索引选择性差，缓存被无效页污染
