索引过大导致无法全部装入内存，会引发频繁磁盘读取、查询延迟陡增；根本原因常是多索引叠加与数据膨胀，需通过分片、归档或精简索引等架构级手段解决，而非单纯扩容内存。
索引太大装不进内存，不是“加点内存就能好”的问题，而是必须面对的架构级约束。WiredTiger 引擎默认把 cacheSizeGB 设为物理内存的 60%，而索引一旦超过这个缓存容量，MongoDB 就会频繁从磁盘读取索引页，查询延迟陡增——尤其是 sort()、find().hint() 这类强依赖索引局部性的操作。
为什么索引大小会超出内存？
常见原因不是单个索引太大，而是多个索引叠加 + 数据膨胀导致总索引体积超标。用 db.collection.stats() 查看 indexSizes 字段，能直接看到每个索引占多少字节；再对比 db.serverStatus().wiredTiger.cache["bytes currently in the cache"]，就知道实际可用缓存有多少。
- 复合索引字段多、字符串字段长（比如
{title: 1, content: "text"}）、或带 TTL 的索引，都会显著放大索引体积 -
smallFiles: true在 mmapv1 引擎下有用，但 WiredTiger 不支持该选项，强行配置无效 - 副本集里 secondary 节点如果启用了
readPreference: "secondary"，而它的内存比 primary 小，就可能出现“primary 能跑通、secondary 报慢查询”的现象
分片前必须确认的三件事
分片不是万能解药，搞错分片键反而会让问题更糟。
- 必须有高基数、写入均匀、查询高频的字段做分片键，比如
userId或tenantId；避免用createdAt（时间倾斜）或status（低基数） - 已有数据需提前预估 chunk 分布：用
sh.status()看当前 chunk 数量和大小，单个 chunk 超过 128MB 就该警惕 - 应用层必须显式带上分片键查询，否则 mongos 会广播到所有 shard，变成全量扫描 —— 这比单机慢得多
垂直扩容的实际瓶颈在哪
加内存看似简单，但很快会撞上两个硬限制：
- WiredTiger 缓存上限受
cacheSizeGB控制，但该值不能超过物理内存的 80%，否则 OS OOM Killer 可能干掉 mongod 进程 - 单机 MongoDB 实例的连接数、锁竞争、journal 写入延迟会随内存增大而恶化，尤其当
resident内存长期 >95% 时，eviction 压力会让所有操作变卡 - 云厂商对单实例内存规格有上限（例如阿里云最大 1024GB），再往上只能换架构
真正需要警惕的是“索引能部分进内存”这种中间状态：查询偶尔快、偶尔超时，监控看不出 spike，但业务方天天报“有时候慢”。这时候靠调参或加内存只是拖延，分片或按租户/时间归档才是落地路径。
