索引构建失败主因是底层约束冲突或状态不一致，关键错误包括：e11000重复键、副本集主切导致中断、后台构建未完成、分片间索引状态冲突；须先识别错误类型再清理重复数据、中止残留构建或同步分片状态。
索引构建失败后，不能直接重试 createIndex 或 createIndexes，尤其在分片集群或存在重复数据时，盲目重试可能加剧不一致或阻塞写入。
为什么索引构建会失败？关键错误类型要先识别
常见失败原因不是“命令没执行”，而是底层约束或状态冲突。必须先看错误信息再动手：
-
E11000 duplicate key error：集合已有重复值，但你在建唯一索引（unique: true） -
InterruptedDueToReplStateChange或Index build failed: interrupted：副本集主节点切换、写入中断或 oplog 被截断 -
Background operation in progress for collection：已有后台索引构建未完成，新请求被拒绝 - 在分片集群上出现
conflicting index build：某个分片上索引状态与其他分片不一致
这些错误决定了恢复路径——是删掉残留状态、清理重复数据，还是强制中止构建。
如何安全中止并清理失败的索引构建
失败的索引构建可能留下半成品索引（system.indexes 里有记录但实际未就绪），或让集合进入只读/阻塞状态。不能靠重启 mongod 解决：
- 先查是否还有进行中的构建：
db.currentOp({ "secs_running": { "$gt": 60 }, "command.createIndexes": { "$exists": true } }) - 对副本集：在 primary 上执行
db.adminCommand({ "abortIndexBuild": "collection_name", "indexName": "idx_name" })（MongoDB 4.2+ 支持） - 对分片集群：需通过
mongos连接，对每个分片单独调用abortIndexBuild；若不可用，可尝试db.runCommand({ "dropIndexes": "collection_name", "index": "idx_name" })清理已注册但无效的索引项 - 检查
db.collection.getIndexes()是否仍有building: true的条目，有则说明元数据残留，需人工干预
重复键导致失败时，不能跳过验证直接建索引
加 dropDups: true 是 MongoDB 3.0 之前的老做法，**该选项已在 3.0+ 彻底移除**。现在必须主动处理重复数据：
- 先定位重复项：
db.collection.aggregate([ { "$group": { "_id": "$field_name", "count": { "$sum": 1 } } }, { "$match": { "count": { "$gt": 1 } } } ]) - 决定保留策略：按时间（取最新）、按业务 ID（取主记录）、或人工核对后删除 —— 不要依赖自动去重
- 删完再建索引：
db.collection.createIndex({ field_name: 1 }, { unique: true }) - 如果无法停写，改用两阶段方案：先建非唯一索引 → 应用层校验并去重 → 再删旧索引、建唯一索引
分片集群上索引构建失败后最易忽略的点
分片环境下的索引失败往往表面正常，实则各分片状态不一致。恢复时容易漏掉以下环节：
- 确认所有分片都完成了同一轮构建：用
sh.status()查看分片分布，再分别连到每个 shard server 执行db.collection.getIndexes() - 检查迁移是否被禁用：之前执行过
setAllowMigrations的，失败后必须手动恢复：db.adminCommand({ setAllowMigrations: "db.collection", allowMigrations: true }) - oplog 大小是否足够：索引构建期间大量写入会撑满 oplog，导致 secondary 同步落后；可通过
rs.printSlaveReplicationInfo()查延迟，必要时扩容 oplog - 不要在构建失败后立刻重建：先
db.collection.dropIndex("name")清理元数据，再等 30 秒以上再重试，避免命令队列冲突
真正麻烦的不是失败本身，而是失败后残留的元数据状态和跨分片不一致——这些不会报错，但会让后续查询、写入、甚至备份行为变得不可预测。
