根本原因是写放大：每次update需同步维护所有相关索引，5个索引中3个含被更新字段，则触发3次b-tree操作；复合索引前缀字段更新开销更大，_id或前缀更新需先删后插；explain仅反映读路径，但keysexamined远大于nreturned暴露索引选择性差，collscan则意味全表扫描加索引维护双重开销。
MongoDB 更新字段后索引变慢，根本原因不是“索引更新慢”，而是写操作本身必须同步维护所有相关索引 —— 每次 updateOne 或 updateMany 都会触发索引键的插入、删除或重排序。这个开销是刚性的，无法跳过。
为什么 update 后索引看起来“变慢”了？
实际是写放大（write amplification）在起作用：一个文档更新，可能要修改多个索引条目。比如你有 5 个索引，其中 3 个包含被更新的字段，那每次更新就要额外执行 3 次 B-tree 插入/分裂操作。这直接拖慢 update 的吞吐和延迟。
- 复合索引中越靠前的字段被更新，开销越大（B-tree 节点重平衡更频繁）
- 如果被更新字段是
_id或索引前缀字段，MongoDB 甚至会先删旧索引项、再插新项，相当于两次 IO -
updateMany批量改 10 万文档？等于重复执行 10 万次索引维护，而不是“一次更新索引”
explain() 看不到索引写开销，但能暴露隐患
explain("executionStats") 只反映读路径（如 IXSCAN、docsExamined），对写操作的索引维护完全不统计。但它能帮你发现间接线索：
- 如果
update前的find查询本身keysExamined远大于nReturned（比如 5000 vs 1），说明索引选择性差 → 后续更新时也要遍历大量索引节点才能定位目标文档 - 执行计划里出现
COLLSCAN？意味着更新条件没走索引 → MongoDB 先全表扫描找文档，再逐个更新并维护索引，双重开销
哪些索引会真正拖慢 update？
不是所有索引都平等。以下三类索引对写性能杀伤力最大：
-
包含高变更频率字段的索引：比如
{status: 1, updatedAt: 1}，而updatedAt每次更新都变 → 每次都触发索引重排 -
冗余复合索引：已有
{a: 1, b: 1}，又建了{a: 1, b: 1, c: 1}，更新c时两个索引都要动 -
未被查询使用的索引：监控显示
index hit ratio长期
真正有效的缓解手段
没有“加速索引更新”的魔法开关，只有减少它、绕过它、或接受它：
- 用
db.collection.getIndexes()定期检查，删掉totalHits为 0 或极低的索引（mongostat或云控制台可查命中率） - 把高频更新字段（如
counter,updatedAt）从复合索引前缀挪到末尾，或单独建索引（降低重排序范围） - 批量更新优先用
bulkWrite而非循环调用updateOne，减少网络往返和事务开销，但索引维护总量不变 - 极端场景（如日志类集合）可考虑关闭索引：
createIndex({x: 1}, {background: false})改为无索引，用时间换写入速度
最常被忽略的一点：索引维护开销永远和数据分布强相关。当一个索引键值高度集中（比如 status: "pending" 占 95%），B-tree 某些分支会异常臃肿，更新这些键对应的文档时，节点分裂更频繁 —— 这种问题 explain 看不见，只能靠 keysExamined / docsExamined 比值和慢日志里的 numYields 推断。
