MongoDB创建索引默认阻塞，需通过$currentOp确认构建状态而非仅看createIndex()返回；getIndexes()仅显示已完成索引，无法反映构建进度；background:true不阻塞读写但仍需监控，可靠判断需结合$currentOp、日志及时间预期。
MongoDB 创建索引时默认是阻塞操作，尤其在数据量大、字段未建索引或后台未启用 background 时，可能卡住几秒到几十分钟不等。直接看命令是否返回不是可靠方式——createIndex() 返回成功只代表“任务已提交”，不代表索引已就绪。
索引是否正在构建：用 $currentOp 查活跃操作
索引构建属于数据库的“长时操作”，会出现在 admin 数据库的 $currentOp 中。关键不是等命令返回，而是查它有没有卡在中间状态：
- 连接到
admin数据库（不是你的业务库）：use admin - 运行聚合查询，过滤出创建索引的操作：
db.aggregate([ { $currentOp: { allUsers: true } }, { $match: { "command.createIndexes": { $exists: true } } } ]) - 结果中若出现
"secs_running": N（N > 0）且"active": true，说明还在构建；若"active": false但没报错，大概率已提交、正等写入完成或等待副本集同步
db.collection.getIndexes() 显示的是“已生效”索引，不是实时进度
这个方法返回当前集合上所有已完成、可被查询使用的索引列表。它不会显示正在构建中的索引，也不会告诉你某个索引还在排队或卡在某阶段。常见误判是：执行了 createIndex() 后立刻调用 getIndexes()，发现没新增就以为失败了——其实只是还没做完。
- 它只反映最终状态，不能用于监控过程
- 如果索引名重复、字段类型冲突或权限不足，
createIndex()会直接报错，getIndexes()不会变 - 唯一能间接确认“开始构建”的信号是：执行
createIndex()后，再查$currentOp确实有对应记录
后台建索引（background: true）仍需监控，只是不阻塞读写
加 { background: true } 参数后，索引构建在后台线程跑，主流程不卡，但不代表它更快或更稳。反而更容易被忽略进度，甚至因资源争抢变慢：
-
background模式下，$currentOp依然可见，但"secs_running"可能增长缓慢，因为调度优先级低 - 某些版本（如 4.2+）对
background建索引有额外限制，比如不能在分片集群的某些配置下使用 - 不要假设
background就等于“安全无忧”——它仍会占用磁盘 I/O 和内存，大量并发建索引可能导致节点抖动
真正可靠的进度判断：结合日志 + db.currentOp() + 时间预期
MongoDB 本身不提供百分比进度条，所谓“查看进度”本质是交叉验证三个信号：
- 查
$currentOp是否存在该操作，且"active": true - 查 mongod 日志（尤其是
journal和index build相关行），搜索关键词IndexBuild或createIndexes - 预估时间：小集合（background，可能持续数分钟；TB 级别务必配
background并盯日志
最常被忽略的一点：索引构建完成后，首次查询触发索引使用前，MongoDB 还要加载索引页到内存，这步没有日志提示，但会影响第一次查询响应速度——所以“完成”和“可用”之间仍有毫秒级延迟。
