前台索引会卡住MongoDB，因其默认获取全局与集合级写锁，阻塞所有读写操作直至构建完成；即使命令行返回，锁仍持续持有，导致请求排队、接口超时、副本延迟激增及磁盘I/O压力剧增。
为什么前台创建索引会让MongoDB卡住
因为前台索引（默认行为）会获取全局写锁，阻塞所有读写操作。哪怕只是建一个单字段索引，只要集合有 10 万+ 文档，db.collection.createIndex({status: 1}) 就会让后续请求排队等待，表现为接口超时、db.currentOp() 显示大量 waitingForLock 状态。
更隐蔽的问题是：即使命令行返回了，也不代表索引建完了——它只是“开始建”，而锁一直持有着，直到构建彻底完成。这对生产环境几乎是不可接受的。
- 锁类型是
Global和Collection级别，影响范围极大 - WiredTiger 引擎在构建期间还会频繁刷盘，加剧磁盘 I/O 压力
- 副本集主节点卡住时，secondary 同步延迟会陡增，可能触发自动故障转移
background: true 并不等于“后台异步执行”
很多人误以为加了 { background: true } 就能立刻返回、完全不阻塞。实际不是：db.collection.createIndex({status: 1}, { background: true }) 在 shell 或驱动中仍是同步调用，命令会卡住直到索引元数据注册完成（通常很快），但真正的构建过程在后台线程里间歇运行——它会周期性释放锁，允许读写继续，代价是整体耗时延长 2–3 倍。
关键点在于：它不阻塞，但没提速；它降低影响，但不消除资源消耗。
- 构建过程仍占用 CPU 和磁盘带宽，高负载下可能拖慢其他查询
- 如果集合正在被大量写入，后台索引构建可能反复重试，日志里会出现
index build failed: interrupted -
db.currentOp()查不到该任务，因为它不在活跃操作列表里；得用db.adminCommand({currentOp: 1, $or: [{secs_running: {$gt: 60}}, {msg: "index"}]})才能捕获
真正影响卡顿的隐藏因素
除了索引模式本身，还有几个常被忽略的硬性瓶颈，它们会让 background: true 也救不了场：
- 磁盘 I/O 能力不足：HDD 上建索引比 SSD 慢 5–10 倍，尤其当
keysExamined和docsExamined差距巨大时（比如扫描 5 万文档只返回 25 条），说明索引设计不合理，但构建过程照旧吃 I/O - WiredTiger 缓存不足：索引构建需要大量内存排序，若
wiredTigerCacheSizeGB设置过小，会频繁 swap，直接卡死进程 - 分片集群中某个 shard 节点宕机或网络不通：整个
createIndex命令会夯住，直到超时（默认 30 分钟），而不是跳过失败节点 - 库表数量过多：每个 collection 对应一个文件句柄，索引构建需打开多个 dhandle，
schemaLock等待时间可能高达秒级，日志里能看到timeWaitingMicros: { schemaLock: 134101710 }
什么时候该放弃 background，改用滚动方案
当集合超过 5000 万文档、或业务对延迟极其敏感（如金融类实时查询），仅靠 background: true 不够稳妥。此时应切换到分片集群下的滚动索引策略：
- 先在单个 shard 上建好索引，验证查询计划是否走
IXSCAN而非COLLSCAN - 用
sh.disableSharding("db.collection")临时关闭分片（慎用，需评估影响） - 或更安全的做法：导出热数据 → 新建带索引的集合 → 切流量 → 补同步冷数据
- 绝对避免在凌晨低峰期批量建多个索引——它们会争抢同一组后台线程和 I/O 队列
最易被忽略的一点：索引构建完成后，WiredTiger 不会立即释放缓存，旧索引残留可能持续影响后续查询性能，建议建完后观察 10 分钟内 mongostat 的 faults 和 netout 波动。
