MongoDB中background: true并非完全不阻塞写入，4.2+ WiredTiger引擎下仍存在I/O与内存竞争，尤其高并发场景；真正瓶颈常是磁盘吞吐、内存不足或swappiness/oplogSize等系统配置不当。
索引创建卡在 background: true 却依然阻塞写入？
不是所有 background: true 都真后台——MongoDB 4.2+ 在 WiredTiger 引擎下，background: true 仅避免阻塞其他索引构建，但对普通写操作仍可能造成锁竞争，尤其在高并发插入场景。真正影响速度的常是 I/O 瓶颈和内存不足。
- 确认引擎：运行
db.serverStatus().storageEngine.name，若返回wiredTiger，则background: true不等于“完全不干扰业务” - 避免在业务高峰建索引；优先选低峰期，或用
db.collection.createIndex(..., { background: true, maxTimeMS: 3600000 })加超时兜底 - 检查
mongod日志里是否有WT_CACHE_FULL或slow journal commit提示，这说明内存或磁盘写入已成瓶颈
createIndex() 执行几小时没反应？查这三件事
常见假死其实是资源耗尽或配置不当，不是 MongoDB “卡住”，而是它在等资源。
- 运行
db.currentOp({ "secs_running": { "$gt": 60 } })查看长时操作，重点关注secs_running和waitingForLock字段 - 检查
/proc/sys/vm/swappiness（Linux）是否 > 1，过高会导致 WiredTiger 缓存频繁换出，大幅拖慢索引构建；建议设为1 - 确认磁盘 I/O 能力：用
iostat -x 1观察%util是否持续 > 90%，await是否 > 50ms；SSD 是硬性要求，HDD 上建大索引极易超时失败
大数据量集合建索引，为什么加 collation 会让速度暴跌？
带 collation 的索引（如指定 locale: "zh"）会触发字符串规范化处理，CPU 和内存开销显著上升，且无法利用默认二进制排序路径。
- 除非业务明确需要大小写/重音敏感排序，否则避免在建索引时加
collation；可后续用find().collation(...)临时指定 - 如果必须用，先确保
db.adminCommand({ setParameter: 1, wiredTigerEngineConfigString: "cache_size=8G" })调大 WT 缓存（需重启生效） - 测试时用小样本验证：对 10 万文档子集建带 collation 的索引，观察耗时是否线性增长；若 10 倍数据导致 100 倍耗时，说明 collation 是主要瓶颈
副本集上建索引，为什么主节点快、从节点同步巨慢？
索引创建本身不复制到从节点——它是在每个节点独立执行的。但 oplog 写入压力 + 从节点重放延迟，会让整体“完成时间”被拉长，且容易因 oplogSize 不足导致同步中断。
- 不要依赖“主节点建完就完事”；需逐个登录 secondary 运行
rs.printSecondaryReplicationInfo()确认同步进度 - 建索引前增大 oplog：用
db.adminCommand({ replSetResizeOplog: 1, size: 10240 })（单位 MB），避免建索引期间大量写入撑爆 oplog - 临时暂停非关键应用写入，或使用
rs.stepDown()切换主节点，让原主变成 secondary 后再建索引，避开主节点写入竞争
swappiness 和 oplogSize 这两个系统级配置，它们不显现在 MongoDB 命令里，却直接决定建索引能不能跑完。 
