调高 maxIndexBuildMemoryUsageMegabytes 可显著加快 background: true 索引构建，但需确保物理内存充足且提前动态设置；该参数默认128MB，仅限单个构建进程，不自动伸缩，超限将触发swap；并发构建受 maxNumActiveUserIndexBuilds 限制，分片集群需各shard单独配置；restore后应先 --noIndexRestore 再统一后台建索引。
直接调高 maxIndexBuildMemoryUsageMegabytes 能显著加快后台索引构建，但仅对 background: true 模式生效，且必须配合足够物理内存 —— 内存不足时反而会触发频繁 swap，拖慢整体进度。
为什么 background 索引构建默认很慢
MongoDB 在 background: true 模式下构建索引时，为避免阻塞读写，会主动限制内存使用量（默认约 128MB），并频繁刷盘、让出锁。这对小集合影响不大，但面对千万级以上文档，I/O 和锁竞争会成为瓶颈。
- 默认值在 3.4+ 版本中是
128（单位 MB），不是自动伸缩的 - 该参数只控制单个索引构建进程的内存上限，与 WiredTiger cache 大小无关
- 若设置值超过可用空闲内存，OS 会 swap，
mongod日志里会出现OutOfMemoryError或长时间卡在INDEXBUILD状态
如何安全地临时调高该参数
必须在索引开始前设置，运行中修改不生效；推荐用 db.adminCommand 动态下发，避免重启：
db.adminCommand({
setParameter: 1,
maxIndexBuildMemoryUsageMegabytes: 2048
})
- 该命令需
clusterAdmin权限，普通数据库用户无法执行 - 值设为
2048（2GB）适用于 32GB 内存的生产节点，建议不超过总内存的 25% - 如果是复制集，该参数只作用于当前节点；从节点会在同步 oplog 时继承相同配置（前提是主节点已设置）
- 执行后可通过
db.serverStatus().indexBuilds查看当前活跃构建是否已应用新内存限制
并发构建多个大索引时的关键约束
即使单个索引变快了，MongoDB 默认仍只允许最多 3 个用户索引同时构建（由 maxNumActiveUserIndexBuilds 控制），超出会排队等待：
- 查看当前并发上限：
db.adminCommand({getParameter: 1, maxNumActiveUserIndexBuilds: 1}) - 如需并行建 6 个索引，必须同步调大该值：
maxNumActiveUserIndexBuilds: 6 - 注意：每个并发索引都会独占一份
maxIndexBuildMemoryUsageMegabytes内存，6 × 2GB = 12GB，务必确认 OS 有足够余量 - 分片集群中，该参数需在每个 shard 的
mongod进程上单独设置，config server 不参与索引构建
restore 后重建索引的典型陷阱
用 mongorestore --drop 恢复大数据集后直接建索引，极易失败或极慢 —— 这不是参数问题，而是流程错位：
-
mongorestore默认边导入边建索引，此时maxIndexBuildMemoryUsageMegabytes完全不生效 - 正确做法是先
--noIndexRestore导入数据，再统一后台建索引 - 若集合已存在且数据量极大，优先用
createIndex(..., {background: true})，别用foreground模式，后者会锁表 - 日志里看到
Index build: building index using bulk method表示走的是高效路径；若长期停留在Index build: scanning collection，大概率是内存不足或磁盘 I/O 瓶颈
真正卡住的地方往往不是参数设多高，而是没意识到 background 模式本身就有隐式资源配额，以及并发数、restore 方式、磁盘吞吐三者之间的连锁制约 —— 调参前先确认这三点是否对齐。
