MongoDB热点索引未常驻内存会导致频繁cache miss和高随机I/O：WiredTiger缓存不足或脏页挤占引发LRU淘汰，使高频查询反复磁盘读索引页，IOPS飙升拖垮集群；可通过serverStatus缓存命中率或explain分析定位，并用预热+evict_gen=0锁定（仅6.0+支持）。
当MongoDB中高频访问的索引无法常驻内存，每次查询都需从磁盘重新加载索引页，直接触发大量随机读I/O，使IOPS在数秒内突破预配上限，拖垮整个集群响应能力。
热点索引未常驻内存的底层机制
WiredTiger引擎将索引以B+树节点形式存储在内存缓存（cache）中，缓存大小默认为实例内存规格的60%。当索引总大小超过该阈值，或缓存被大量写入脏页挤占时，LRU淘汰策略会将不活跃的索引页刷出内存。若某复合索引被高频查询反复使用（如{"status":1,"created_at":-1}用于订单列表分页），但其节点频繁进出缓存，就会形成“索引抖动”——每次查询都命中cache miss，强制发起磁盘页读取。
这一步操作本身不报错，但【每个索引页缺失都会引发一次4KB～64KB的随机磁盘读】，而磁盘随机I/O延迟远高于顺序读，单次可能达5–20ms。当QPS升至300+，IOPS轻松突破3000，远超普通云盘的1000–2000预配值。
验证索引是否真正常驻内存
方法一：检查当前缓存中索引页占比
在mongo shell中执行：db.serverStatus().wiredTiger.cache["pages read into cache"] 与 db.serverStatus().wiredTiger.cache["pages requested from the cache"] 比值若低于95%，说明索引页大量缺失。
方法二：定位具体缺失的索引
运行慢查询的explain("executionStats")，观察"executionStats.totalKeysExamined"与"nReturned"比值。若比值＞5且"stage"为IXSCAN，再检查"indexName"字段——该索引就是热点但未驻留的嫌疑对象。
注意：不要依赖db.stats()中的"indexCount"或"indexSize"，它们只反映元数据体积，不体现内存驻留状态。
强制让热点索引常驻内存的操作路径
第一步：确认目标索引名称和所在集合
通过db.getCollectionNames()列出库内所有集合，再对疑似高QPS集合执行db.collection_name.getIndexes()，找到命中率最高的索引名（通常含status、type、ts等字段）。
第二步：预热索引到WiredTiger缓存
执行db.collection_name.find({索引字段: {$exists: true}}).hint("索引名").limit(1).toArray() → 重复执行10次 → 确保索引B+树根节点和各级分支页全部载入内存。
第三步：锁定索引不被LRU淘汰
连接mongod进程后，执行：db.runCommand({"setParameter": 1, "wiredTigerEngineConfigString": "cache_size=8G, eviction=(evict_gen=0)"}) → 其中cache_size必须≥该索引实际占用字节数的1.5倍（可通过db.collection_name.stats().indexDetails.索引名.size估算）。
这一步操作起来很简单，直接把命令粘贴进shell回车即可，但【evict_gen=0参数仅在MongoDB 6.0+版本生效，低版本会静默忽略】。
