真要低延迟、高吞吐，必须用WiredTiger+精准字段控制+TTL+应用层缓存协同实现“伪内存效果”；inMemory引擎仅限企业版、不支持复制集与分片、数据重启即丢，实际不可行。
高频访问的热点数据，**不能只靠加大 WiredTiger 缓存硬扛**——它本质仍是磁盘引擎，热数据反复刷入/淘汰缓存反而加剧内存压力和 I/O。真要低延迟、高吞吐，得让热点数据“常驻内存”，而 MongoDB 官方唯一原生支持的内存引擎是 inMemory，但它仅限企业版，且不兼容复制集与分片集群。所以实际可行路径只有一条：**用 WiredTiger + 精准字段控制 + TTL + 应用层缓存协同，把“伪内存效果”做到极致。**
为什么不用 inMemory 引擎？企业版限制与架构陷阱
很多人第一反应是启用 inMemory 存储引擎，但现实很骨感：
-
inMemory引擎在社区版中根本不可用，必须购买 MongoDB Enterprise Advanced 许可 - 它不支持副本集（
replication）和分片（sharding），意味着无法做高可用或水平扩展 - 数据重启即丢（无持久化），必须搭配外部备份机制，运维复杂度陡增
- 内存用量完全由文档数量 × 文档大小决定，无法像 WiredTiger 那样按需压缩或淘汰，极易 OOM
换句话说，除非你跑的是单节点、无灾备要求、数据量可控的内部工具服务，否则 inMemory 不是解法，而是新坑。
WiredTiger 缓存怎么调才真正“喂饱”热点数据？
WiredTiger 的 cacheSizeGB 不是越大越好，关键在于让热点数据“稳住不被淘汰”。默认 50% 物理内存只是起点，真实调优要看 db.serverStatus().wiredTiger.cache 中三个值：
-
bytes currently in the cache持续 > 90%maximum bytes configured→ 缓存太小，频繁淘汰 -
pages evicted by age明显高于pages evicted by usage→ 热点数据被老化策略误踢，说明工作集大于缓存 -
tracked dirty bytes in the cache长期偏高（如 > 200MB）→ 写密集场景下脏页堆积，可能拖慢读响应
实操建议：
- 先用
db.runCommand({collStats:"orders"})估算热点集合平均文档大小 × 预估活跃文档数，得出最小工作集内存需求 - 将
storage.wiredTiger.engineConfig.cacheSizeGB设为该值的 1.3–1.5 倍（留出索引、临时排序等开销） - 禁用自动老化干预：
storage.wiredTiger.engineConfig.configString: "eviction=(threads_max=4,hard_max_percent=95)"，避免冷数据挤占热区
字段精简不是“删字段”，而是按访问路径做投影裁剪
很多团队以为“只查 _id 和 status”就够了，结果发现慢查询日志里还是扫了 2MB 文档——因为没用覆盖索引，MongoDB 仍要从磁盘加载完整文档再投影。真正有效的精简分三层：
-
索引层：对高频查询字段建复合索引，并把所有返回字段也包含进去，例如
db.orders.createIndex({user_id:1, created_at:-1}, {projection:{_id:1, status:1, amount:1}})（注意：WiredTiger 支持索引内嵌字段，但 projection 参数需 MongoDB 6.0+） -
查询层：强制使用
find({user_id:xxx}, {_id:1, status:1, amount:1})，禁止{}全字段返回 -
模型层（如 Laravel-MongoDB）：在 Eloquent 模型中覆写
$visible或用select()链式调用固化字段白名单，避免业务代码漏写
特别注意：created_at、updated_at 这类时间戳字段如果只用于排序不用于展示，就别放进投影——它们虽小，但乘以百万级 QPS 就是带宽浪费。
TTL 索引 + 归档脚本才是热冷分离的落地抓手
光靠内存配置和字段裁剪，解决不了数据自然老化问题。真正的热冷分离必须有明确的时间边界和自动执行机制：
- 对订单、会话、实时日志等典型热点集合，直接建 TTL 索引：
db.sessions.createIndex({last_active:1}, {expireAfterSeconds:1800})（30 分钟未活跃即删） - 归档任务不要依赖应用层定时器，改用 MongoDB 自身的
changeStream监听删除事件，触发异步归档到温数据集合（如orders_archive），避免主业务链路阻塞 - 归档后立即在原集合上
db.runCommand({compact:"orders"})，回收空间并减少 WiredTiger 的 page split 开销
最容易被忽略的一点：TTL 删除是后台线程异步执行的，高峰期可能积压。务必监控 metrics.record.moves 和 wiredTiger.cache.pages evicted 是否突增——那是 TTL 正在疯狂刷脏页的信号。
