最直接有效的做法是临时禁用索引而非暂停——因mongodb无pauseindexing机制，索引为写操作硬依赖，唯一可靠方式是先dropindexes再background重建，避免锁表与同步风险。
不能“暂停”索引维护，只能临时禁用索引——这是最直接有效的做法。
为什么不能暂停索引，而必须删掉再重建
MongoDB 没有提供 pauseIndexing 或类似运行时开关。索引是写操作的硬依赖：只要索引存在，每次 insert、update、delete 都会同步更新对应 B-Tree 结构。所谓“暂停”，实际是绕过这个机制——唯一可靠方式就是先移除索引，等批量写完再重建。
- 试图用
background: true创建索引，只影响“新建索引”过程，不改变已有索引对写入的影响 -
db.currentOp()查不到“索引维护中”的独立操作，它只显示正在执行的写/读命令，索引更新是这些命令的隐含开销 - 没有配置项（如
indexBuildRetry或disableIndexUpdates）能动态关闭索引写入路径
批量插入前必须执行的三步清理
在导入几十万以上文档前，这几步缺一不可：
用Apache Spark进行大数据处理
下载
本文档主要讲述的是用Apache Spark进行大数据处理——第一部分：入门介绍；Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架。最初在2009年由加州大学伯克利分校的AMPLab开发，并于2010年成为Apache的开源项目之一。 在这个Apache Spark文章系列的第一部分中，我们将了解到什么是Spark，它与典型的MapReduce解决方案的比较以及它如何为大数据处理提供了一套完整的工具。希望本文档会给有需要的朋友带来帮助；感
- 运行
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 后再建，否则从节点可能因索引缺失+查询压力激增而抖动甚至宕机。
