MongoDB在大数据量插入时如何暂停索引维护

最直接有效的做法是临时禁用索引而非暂停——因MongoDB无pauseIndexing机制，索引为写操作硬依赖，唯一可靠方式是先dropIndexes再background重建，避免锁表与同步风险。

不能“暂停”索引维护，只能临时禁用索引——这是最直接有效的做法。

为什么不能暂停索引，而必须删掉再重建

MongoDB 没有提供 pauseIndexing 或类似运行时开关。索引是写操作的硬依赖：只要索引存在，每次 insert、update、delete 都会同步更新对应 B-Tree 结构。所谓“暂停”，实际是绕过这个机制——唯一可靠方式就是先移除索引，等批量写完再重建。

• 试图用 background: true 创建索引，只影响“新建索引”过程，不改变已有索引对写入的影响
• db.currentOp() 查不到“索引维护中”的独立操作，它只显示正在执行的写/读命令，索引更新是这些命令的隐含开销
• 没有配置项（如 indexBuildRetry 或 disableIndexUpdates）能动态关闭索引写入路径

批量插入前必须执行的三步清理

在导入几十万以上文档前，这几步缺一不可：

• 运行 db.collection.dropIndexes() 删除所有非 _id 索引（_id 索引无法删除，且必须保留）
• 确认集合无活跃写入——否则新写入会因缺失索引而变慢，甚至触发大量全表扫描
• 检查副本集 oplog 容量是否足够：索引重建期间主节点可能产生大量 oplog 条目，oplogSizeMB 过小会导致从节点同步延迟或失败

重建索引时务必加 background: true

数据插入完成后，重建索引若不加 background: true，会锁死整个集合，阻塞所有写操作。尤其对大集合，前台建索引可能持续数小时。

• 正确写法：db.collection.createIndex({field: 1}, {background: true})
• 错误写法：db.collection.createIndex({field: 1})（默认前台，锁集合）
• 验证是否后台运行：db.currentOp({ "secs_running": { "$gt": 0 }, "ns": "db.collection" }) 中查 "msg": "Index Build" 并确认 "progress": {...} 存在

别忽略 reIndex() 的副作用

有人误以为 db.collection.reIndex() 是“安全重建”，但它会先删所有索引再重建，过程中集合仍无有效索引——和手动 dropIndexes + createIndex 效果一致，但多了一次全量扫描开销，且无法控制单个索引的 background 参数。

• reIndex() 不接受 background 选项，强制前台执行
• 它还会重建 _id 索引，虽无害但浪费时间
• 真正需要的是按需重建：只对刚插入数据后急需加速查询的字段建索引，而非全量重建

最容易被忽略的点是：重建索引不是插入结束就立刻执行。要等所有批量写入事务提交完成、secondary 节点追平 oplog 后再建，否则从节点可能因索引缺失+查询压力激增而抖动甚至宕机。