maxIndexBuildMemoryUsageMegabytes需在createIndex前用db.adminCommand动态设置且需clusterAdmin权限，仅作用于单次索引构建第一阶段；第二阶段排序内存由独立参数sortBufferSizeMB控制，两者叠加易OOM。
maxIndexBuildMemoryUsageMegabytes 设置后没生效？
该参数必须在 createIndex 命令执行前设置，运行中修改对已启动的索引构建无效。常见错误是先发 createIndex({a: 1}, {background: true})，再调 db.adminCommand —— 此时构建已用默认 128MB 启动，新值不会回填。
正确做法是：先动态设置，再建索引，且需 clusterAdmin 权限：
db.adminCommand({ setParameter: 1, maxIndexBuildMemoryUsageMegabytes: 2048 })
验证是否生效可查：db.serverStatus().indexBuilds，确认当前活跃构建的 memoryLimitBytes 字段是否更新。
- 该参数只作用于单个索引构建进程，不是全局内存池
- 若用复制集，只需在主节点设置；从节点同步 oplog 时会继承相同配置
- 分片集群必须在每个 shard 的 mongod 上单独执行该命令，config server 不参与索引构建
为什么调高了内存还是 OOM？
根本原因常被忽略：MongoDB 索引构建分两阶段，maxIndexBuildMemoryUsageMegabytes 只控制第一阶段（扫描+键生成）的内存，而第二阶段排序使用的 sortBufferSizeMB 是另一套独立内存，不走 WiredTiger cache，也不受前者限制。
例如设了 maxIndexBuildMemoryUsageMegabytes: 2048，但 sortBufferSizeMB 仍为默认 512MB，若同时并发建多个索引，总内存 = 并发数 × (2048 + 512) MB —— 很容易超出物理空闲内存，触发系统 swap 或 OOM killer。
- 务必同步检查并调低
sortBufferSizeMB（建议 128–512），尤其在容器环境要匹配容器内存 limit - 用
dmesg -T | grep -i "killed process"确认是否真被 OOM killer 终止 -
mongod日志里出现Sort key buffer size exceeded就是排序阶段爆内存的明确信号
background: true 模式下内存为何更难控？
很多人误以为 background: true 是“省内存模式”，其实它只是通过频繁 yield 让出锁来避免阻塞读写，内存占用反而可能更高：构建周期拉长、中间状态驻留时间变久、WiredTiger 缓存压力持续存在。
真正可控内存的做法是改用 foreground 模式 + 数据范围控制，比如分批建索引：
- 用
$match+$merge或应用层按时间/ID 分段，每次只对百万级文档建索引 - 禁用
background: true，避免隐式锁让渡带来的调度开销和内存碎片 - restore 后优先用
--noIndexRestore，再统一后台建索引，避免恢复时索引与数据不同步
7.0 版本特有的坑：allowDiskUse 默认开启但不适用于索引构建
MongoDB 7.0 默认开启 allowDiskUseByDefault: true，但这仅影响查询和聚合中的 $sort 阶段，**对 createIndex 完全无效**。索引构建全程必须内存完成，无法落盘 —— 这是引擎设计决定的，不是配置能绕过的。
所以别指望靠 allowDiskUse: true 解决索引内存超限，它对 createIndex 命令无意义。唯一路径仍是：控制单次构建数据量 + 调整两个内存参数 + 严控并发数。
最容易被跳过的点是：并发索引数由 maxNumActiveUserIndexBuilds 控制，默认仅 3，但每个都独占一份 maxIndexBuildMemoryUsageMegabytes 和 sortBufferSizeMB —— 这个乘数关系，上线前必须手算一遍总内存需求。
