删除索引会影响查询性能，具体取决于索引用途、删除方式及应用依赖：高频查询失去索引将退化为全表扫描，导致慢查询、CPU/I/O上升；应优先用MongoDB 4.4+隐藏索引验证影响，再结合explain和慢日志确认执行路径；副本集需逐节点手动删除，大索引删除可能引发I/O瓶颈，且dropIndex不支持background参数。
会，但影响方式和程度取决于你删的是什么索引、怎么删、以及应用是否依赖它。
删错索引会导致查询变慢甚至超时
如果被删的索引正被高频查询使用（比如 find({status: "pending"}) 依赖 {status: 1}），删除后查询可能从索引扫描退化为全表扫描。现象包括：
- 慢查询日志里
executionStats.totalDocsExamined突增几倍甚至几十倍 - 监控中
queryExecutorCPU 或磁盘 I/O 上升，query延迟 P99 跳变 - 某些聚合管道卡在
IXSCAN阶段消失，变成COLLSCAN
别只看 db.collection.getIndexes() —— 它只告诉你“索引存在”，不告诉你“是否真在用”。必须结合 explain("executionStats") 或慢查询日志确认实际执行路径。
隐藏索引比直接删除更安全
MongoDB 4.4+ 支持隐藏索引，这是验证删除影响的最低风险方式：
- 执行
db.runCommand({collMod: "collection", index: {keyPattern: {field: 1}, hidden: true}})，不是hideIndex()（该方法只是封装，且易因 keyPattern 不一致失败） - 隐藏后，
explain("executionStats")的executionStages里绝不会出现该索引名——这是唯一可信验证方式 - 注意：如果代码里写了
.hint("idx_name")，隐藏完全失效；countDocuments()也不走 planner，不能用来判断
隐藏后观察 24–72 小时真实流量下的 executionTimeMillis 和 totalDocsExamined，再决定是否删除。
副本集里删索引必须逐节点执行
dropIndex 不写 oplog，不会自动同步到其他节点。常见错误是只在主节点删了，但从节点仍保留旧索引，导致：
- 读请求打到从节点时，
explain()显示用了已删索引，但性能异常 - 查询计划不一致，同一语句在不同节点执行路径不同
- 延迟节点上线后“回退”出已删索引，长期残留
正确做法：rs.status() 查清所有存活节点（含隐藏节点），挨个连上去执行 db.collection.dropIndex("name_1")。混版本集群（如 4.4 + 5.0）更要手动对齐，别依赖 majority 写关注。
大索引删除可能拖慢写入
删一个几 GB 的复合索引，即使 MongoDB 4.2+ 优化了锁机制，仍可能触发大量磁盘 I/O：
- 现象：
wt_write_lock时间飙升，写超时增多，尤其在 SSD 性能瓶颈时 -
background: true对dropIndex无效——这是常见误解，该参数只对createIndex生效 - 建议加超时：用
db.runCommand({dropIndexes: "collection", index: "name_1", maxTimeMS: 30000})，避免长阻塞
真正容易被忽略的是：删完立刻查 db.currentOp({ "secs_running": { "$gt": 5 } })，确认没残留长事务——有些删除操作在后台清理 B-tree 结构，会卡住后续命令。
