重启后聚合查询变慢的根本原因是wiredtiger cache清空导致冷启动io瓶颈，叠加secondary节点状态切换引发的资源竞争；需通过预热、流量调度和同步优化缓解。
重启本身不会直接“让聚合缓存失效”，MongoDB 也没有传统意义上的“聚合查询缓存”。所谓“聚合变慢”，其实是 WiredTiger 存储引擎的 cache 冷启动导致的 IO 瓶颈，叠加副本集状态切换带来的同步行为干扰——这在刚重启的 secondary 节点上尤为明显。
为什么重启后聚合查询响应变长？
根本原因是 WiredTiger cache 在 mongod 进程重启时被清空，所有数据页需重新从磁盘加载。聚合操作（尤其是涉及 $lookup、$unwind 或大范围 $match）会触发大量随机读，而冷 cache 下 page fault 频繁，iowait 持续高于 90%，CPU 利用率却很低，表现为“卡顿”而非“忙”。
-
cache默认大小为物理内存的 50%，但重启即归零，无法复用旧热点页 - secondary 节点若处于
STARTUP2或RECOVERING状态，会优先拉取 oplog，抢占磁盘 IO 和 cache 资源，进一步挤压聚合查询的资源配额 - 如果该节点还承担读流量（
readPreference=secondary），聚合请求和复制线程会竞争同一套 WT cache 和磁盘队列
rs.status() 显示 SECONDARY 但聚合仍慢，是不是同步没完成？
不一定。只要 stateStr 是 SECONDARY，说明复制链路已就绪；但“就绪”不等于“数据热”。此时可能：
- oplog 已追平，但集合数据文件尚未预热 —— 尤其是大集合的索引页、B-tree 中间节点还没加载进 cache
- 节点刚完成 initial sync，
db.stats().objects正常，但db.collection.stats().wiredTiger.block-manager.fileSize对应的 WT 文件仍处于冷态 - 应用在节点刚升为 SECONDARY 后立刻发聚合请求，而 cache 预热需要时间（几十秒到数分钟，取决于数据规模）
如何快速缓解重启后的聚合性能抖动？
核心思路是“绕过冷 cache 的随机读放大”，优先触发顺序扫描加载热点页：
- 在重启后的 secondary 上，执行一次全库轻量扫描：
mongosh --eval 'db.getMongo().getDBNames().forEach(dbname => { db.getSiblingDB(dbname).getCollectionNames().forEach(coll => { db.getSiblingDB(dbname).getCollection(coll).find().limit(1).toArray() }) })'（仅触发元数据和首文档加载，开销可控） - 对高频聚合涉及的集合，手动预热索引：
db.collection.aggregate([{$indexStats:{}}, {$group:{_id:null, count:{$sum:1}}}], {allowDiskUse:true}) - 临时将读流量切走：在应用层设置
readPreference=primary或剔除该节点的负载均衡权重，等 2–5 分钟再逐步恢复 - 确认
syncSourceHost配置合理（避免从高延迟或高负载节点同步），减少复制线程对本地 IO 的持续争抢
真正影响聚合响应的，从来不是“有没有缓存”，而是“缓存里有没有这次查询要的那几页数据”。重启后最危险的不是慢，而是误判——把 cache 冷启动当成配置错误或查询写法问题去调优，反而掩盖了真正的瓶颈点。
