dropIndex 在 MongoDB 4.2+ 对非唯一/非TTL/非文本索引通常不阻塞写入，但唯一索引、TTL索引或旧版本仍可能触发短暂全局写锁；副本集需逐节点执行，否则从节点残留索引导致查询异常。
dropIndex 会阻塞写入吗
会，但取决于 MongoDB 版本和索引类型。MongoDB 4.2+ 对大多数 dropIndex 操作做了优化，非唯一、非 TTL、非文本索引在后台执行时通常不阻塞集合写入；但如果是唯一索引、TTL 索引，或在副本集主节点上执行，仍可能触发短暂的全局写锁（尤其在 4.0 及更早版本）。
常见错误现象：db.collection.dropIndex("name_1") 执行后，应用突然出现大量写超时，监控显示 wt_write_lock 时间飙升。
- 使用场景：线上服务正在高频写入，又急需清理一个不再使用的冗余索引
- 参数差异：不带
{ background: true }的dropIndex在旧版本中默认同步执行；background: true仅对创建索引有效，对dropIndex无效 —— 别被名字误导 - 性能影响：删除大索引（比如几 GB 的复合索引）可能触发大量磁盘 I/O，间接拖慢其他操作
如何安全地在生产环境删索引
核心原则：先验证、再降级、最后删除。不要直接在主节点上跑 dropIndex。
- 先查索引用途：
db.collection.getIndexes()看name和key，再结合慢查询日志或explain("executionStats")确认该索引是否真没被用到 - 在从节点上预演：
rs.slaveOk(); db.collection.dropIndex("old_status_1_createdAt_-1")，观察是否有报错或延迟突增 - 选低峰期，在主节点执行，并加超时：
db.runCommand({ dropIndexes: "collection", index: "name_1", maxTimeMS: 30000 }) - 删完立刻检查：
db.collection.getIndexes()确认消失，再看db.currentOp({ "secs_running": { "$gt": 5 } })排查残留长事务
副本集里删索引的坑
副本集不是自动同步索引变更的。dropIndex 只作用于当前连接的节点，不会自动传播到其他成员 —— 这是很多人误以为“删完了”，结果从节点还在用旧索引导致查询计划异常的根本原因。
- 常见错误现象：主节点删了索引，但某个从节点仍返回
"indexName" : "old_idx"在explain结果里，且查询变慢 - 必须逐个节点执行：
rs.status()查清所有存活节点，再分别连上去运行dropIndex - 注意隐藏节点/延迟节点：它们可能长期离线，上线后会重放 oplog，但
dropIndex不记入 oplog，所以这些节点会“回退”出已删索引 - 兼容性影响：MongoDB 5.0+ 支持
dropIndex命令在 majority 写关注下保证一致性，但前提是所有节点都 >=5.0；混版本集群务必手动同步
替代方案：用 renameCollection 避开风险
当索引规模大、业务又极度敏感时，比硬删更稳的方式是“换表”：把原集合重命名，建新集合并只导入需要的索引。
- 适用场景：要删的是包含多个字段的大型复合索引，且无法接受任何写阻塞
- 实操步骤：
db.collection.renameCollection("collection_old")→db.createCollection("collection")→db.collection_old.find().forEach(...)导入 → 按需建新索引 → 切流量 - 关键点：rename 是原子操作，不锁数据；但导入期间新写入需双写或暂停，得配合应用层灰度
- 别忽略
_id索引：新集合会自动建_id索引，但如果你删过自定义_id索引，这里容易漏掉约束逻辑
最常被忽略的其实是索引依赖——比如某个聚合管道用了 $lookup，而被查集合的索引刚被删了，错误不会立刻暴露，而是某次匹配变慢后才浮现。删之前，翻一遍应用代码里的 explain 和聚合语句。
