MongoDB 4.4 首次引入同步建索引，允许构建期间继续读写（不违反约束），但不可恢复；5.0 升级为可恢复索引创建，支持中断后从检查点续建，需 fCV 设为 "5.0" 且仅对新索引生效。
同步建索引（Simultaneous Indexing）在 4.4 中首次落地
MongoDB 4.4 引入了 Simultaneous Indexing，但注意：它不是“异步”或“后台”建索引，而是允许在索引构建过程中继续插入、更新、删除数据——前提是这些操作不违反索引约束（如唯一性）。它的核心目标是缓解长耗时索引创建对写入可用性的冲击。
实际效果取决于索引类型和负载：
- 对于非唯一索引，
createIndex命令执行期间，写操作基本不受阻塞 - 对于唯一索引，仍需在构建完成前对冲突写入做实时校验，可能引入轻微延迟
- 底层仍由主节点单线程驱动索引扫描与构建，CPU 和 I/O 并未并行化
- 若在构建中发生节点宕机，索引状态回滚，需重试；无断点续建能力
createIndex 在 5.0 变成可恢复任务
MongoDB 5.0 将索引创建升级为「可恢复的索引创建任务」（resumable index build），这是质变。它不再依赖单次连续执行，而是把构建过程拆解为带检查点（checkpoint）的阶段任务。
这意味着：
- 如果建索引中途因故障中断（如 mongod crash、kill -9、网络断连），重启后能从最近检查点继续，而非从头开始
- 支持在副本集上滚动构建：对每个 secondary 节点单独恢复，避免全集群同步等待
- 仍不默认启用并发多线程扫描，但恢复机制让长索引更可控、更贴近生产容忍度
- 必须确保
featureCompatibilityVersion设为"5.0"才能启用该行为
为什么不能直接用 5.0 的恢复能力回填 4.4 集合？
可恢复建索引依赖新的元数据格式和 oplog 记录方式，4.4 的存储引擎（WiredTiger）未实现对应日志结构。即使你升级到 5.0，对 4.4 时代创建的集合执行 createIndex，初始构建阶段仍走传统路径；只有在首次以 5.0 fCV 启动后新建/重建的索引，才真正享受恢复语义。
常见误操作包括：
- 升级后立即对旧集合建唯一索引，期望自动获得恢复能力 → 实际仍是不可恢复的传统流程
- 未运行
db.adminCommand({setFeatureCompatibilityVersion: "5.0"})就尝试建索引 → 系统降级使用 4.4 行为 - 在分片集群中只升级了 mongos 或部分 shard，导致
createIndex请求被转发到低版本 shard → 恢复逻辑失效
实际选型建议：别只盯“同步 vs 可恢复”
真正影响线上决策的，往往是组合策略：
- 对大集合建索引，优先在维护窗口用
hidden: true先建好索引（4.4+ 支持），观察查询计划是否采纳，再collMod取消隐藏 —— 这比赌恢复机制更稳妥 - 5.0+ 环境下，对关键唯一索引，务必搭配
writeConcern: {w: "majority"}，防止因主节点写入成功但多数副本未同步导致恢复后数据不一致 - 不要忽略
background: true参数：它在 4.4 和 5.0 中都存在，但作用不同——4.4 中仅降低 I/O 优先级；5.0 中配合可恢复机制，能让长时间任务更“温顺”
最易被忽略的一点：可恢复 ≠ 自动重试。MongoDB 不会主动检测失败并重发建索引命令，你得自己监控 currentOp 或日志中的 indexBuilds 状态，并在必要时手动调用 reIndex 或重新发起 createIndex。
