mongodb 5.0 索引构建性能提升源于锁粒度细化、可恢复机制和后台调度优化，而非自动并行扫描；建索引时仅元数据变更瞬时加锁，非唯一索引写入基本不受影响，唯一索引仅引入微秒级校验延迟。
MongoDB 5.0 的索引构建在性能上确实比 4.2 有实质性提升，但不是靠“自动并行扫描”实现的——它依然默认单线程扫描集合，真正的改进集中在锁粒度、恢复能力与后台资源调度三个层面。
索引构建期间是否还阻塞写入？
4.2 的 createIndex 在构建全程对集合加全局排他锁（WiredTiger 层面），写操作会排队等待；而 5.0（需 fCV 设为 "5.0"）已移除该锁，仅在元数据变更瞬间加短时锁。这意味着：
- 非唯一索引构建中，
insert/update/delete基本不受影响 - 唯一索引仍需实时校验冲突，可能引入微秒级延迟，但不会导致写请求长时间挂起
- 若业务依赖强一致性写入（如金融类事务），建议避开建索引窗口，因为校验逻辑仍串行执行
为什么说“可恢复”比“并行”更关键？
5.0 引入的「可恢复索引创建」不是性能加速器，而是容错增强器。它把构建过程拆成带检查点的阶段任务，中断后能从最近 checkpoint 续建。这直接影响运维节奏：
- 副本集滚动建索引时，secondary 节点宕机重启后不再重头开始，节省数小时甚至数天时间
- 分片集群中，某个 shard 建索引失败，其他 shard 不受影响，
createIndex请求不会被整体阻塞 - 必须先运行
db.adminCommand({setFeatureCompatibilityVersion: "5.0"})，否则即使版本是 5.0，也退化为 4.2 行为
大集合建索引时内存与并发的实际表现
5.0 并未增加 maxIndexBuildMemoryUsageMegabytes 这类参数，也没有开放多线程扫描开关。它的内存优化体现在 WiredTiger 缓存复用和 oplog 批处理上：
- 构建过程中，WiredTiger 更积极复用 page cache，减少重复读盘，对 SSD 友好
- oplog 写入合并更紧凑，降低 journal 压力，间接缓解 I/O 竞争
- 若你真需要提速，仍得靠老办法：分离节点、本地建索引、再 rejoin，且要确保 oplog 窗口 > 节点离线时间
真正容易被忽略的是：5.0 的可恢复机制只对新创建的索引生效，升级后直接对 4.2 时代的老集合建索引，仍是不可恢复的传统流程——元数据格式不兼容，这点连 collMod 都无法绕过。
