有效但限制更严格：background: true 仍存在且默认 false，后台建索引期间查询不可见、secondary 前台重建、资源消耗显著，仅大数据量且无法停机时才推荐使用。
有效，但行为和限制比早期版本更严格，尤其在副本集、写性能和索引可用性上容易被误判。
background: true 仍可正常使用，但默认值没变
截至 MongoDB 6.x 和 7.x（2026 年主流部署版本），background 选项依然存在且默认仍是 false。它没被废弃，也没变成默认行为——你必须显式传入 { background: true } 才启用后台模式。
-
db.users.createIndex({ email: 1 })→ 前台阻塞，整个集合读写暂停 -
db.users.createIndex({ email: 1 }, { background: true })→ 后台异步，其他连接可继续读写 - 注意：
ensureIndex()已弃用多年，必须用createIndex()
后台索引创建期间，查询仍然无法命中新索引
这是最常被忽略的事实：即使加了 background: true，索引在构建完成前对查询完全不可见。执行 explain() 或查看 getIndexes() 都不会显示该索引处于“构建中”状态，它要么不存在，要么已就绪。
- 新建索引期间所有查询仍走全表扫描或旧索引，性能无改善
-
db.collection.getIndexes()只返回已完成的索引，不暴露进行中的构建任务 - 没有内置命令能实时查“进度百分比”，只能靠
currentOp()看是否有createIndexes操作在运行
副本集里 secondary 不会自动同步后台索引构建
主节点（primary）上用 background: true 创建索引，secondary 节点不会以同样方式重建——它们会等 primary 完成后，在前台重建索引，期间该 secondary 将短暂不可读（或只读受限）。
- secondary 上索引构建仍是前台操作，会阻塞其本地读请求
- 如果你有多个 large secondary，建议错峰重建：逐个临时摘出、单独执行
createIndex(..., { background: true })、再重新加入集群 - 不要在维护窗口外对大集合启用
background: true，否则 secondary 可能因 I/O 压力拖慢整个复制链路
后台索引不是“零代价”，写放大和锁竞争依然存在
background: true 不等于“不抢资源”。它只是把锁粒度从“集合级排他锁”降为“文档级意向锁”，但仍会显著拖慢写入吞吐，并可能触发 page fault 或内存压力。
- 写入延迟上升 20%–50% 很常见，尤其在 SSD 性能瓶颈或 WiredTiger cache 不足时
- 如果同时运行大量写操作 + 后台索引构建，WiredTiger 可能频繁刷盘，导致
wt_checkpoint延迟升高 - 避免在业务高峰跑
createIndex(..., { background: true })；哪怕加了 background，它还是吃 CPU、I/O 和内存
真正关键的不是“能不能加 background”，而是确认你是否真的需要它——如果集合不大、停机窗口可控，前台建索引反而更快更稳；只有当数据量超千万、且业务无法接受秒级写阻塞时，才值得承担 background 带来的不确定性与资源开销。
