高频更新字段建索引会显著放大写入开销，因WiredTiger需为每次更新执行索引项删除+插入、引发页分裂、多页刷盘与锁争用，导致单次更新触发3～8次随机I/O、吞吐腰斩。
高频更新字段上建了索引，每次update都会触发对应索引项的删除+插入，WiredTiger引擎需同步刷多页、争锁、加剧页分裂，单次逻辑更新可能引发3～8次随机I/O，写入吞吐直接腰斩。
为什么高频更新字段加索引会放大写入开销
WiredTiger对每个索引字段的变更都执行原子性维护：先定位旧索引条目→标记为失效→在新位置写入有效条目→异步清理。当字段每秒被update 50+ 次，索引页频繁分裂+合并，internalPages占比飙升，cache中驻留的脏页数持续超阈值。
db.collection.stats({indexDetails: true})里查到tree.depth ≥ 6 或 internalPages / totalPages > 40%，说明该索引已成写放大源。
【高频更新字段建索引后，索引B-Tree结构会快速劣化，不是慢在磁盘，是慢在内存页管理失效】
识别正在拖垮写入的“高危索引”
方法一：用慢写日志反向追踪
执行 db.setLogLevel(1, "write") → 触发一批 update 操作 → 抽样 db.adminCommand({getLog:"slow"})，筛选出"planSummary"含该索引名且"numYields"> 3 的日志条目。若7天内出现≥50次，即为高危信号。
方法二：看索引访问与更新比值
运行 db.collection.stats().indexDetails["idx_status_updatedAt"].accesses.ops 获取该索引被查询命中的次数，再用 db.collection.stats().count() × 平均每日update频次估算总更新量。若前者 ÷ 后者
安全移除高危索引的三步验证
第一步：确认该索引未被$text、$geoWithin或分片键引用
运行 sh.status() 查分片键；运行 db.collection.getIndexes() 扫描所有索引定义，排除含"text"、"2dsphere"、"2d"等关键字的索引。
第二步：验证最近7天慢日志中无该索引的planSummary记录
db.adminCommand({getLog:"slow"})返回结果中逐条grep索引名，出现次数为0才通过。
第三步：检查该索引是否被任何活跃聚合管道显式hint
在mongostat或Performance Advisor中查看近期top耗时聚合操作，确认其explain("executionStats")输出中没有"indexName":"idx_status_updatedAt"字段。
三项全部满足，可执行 db.collection.dropIndex("idx_status_updatedAt")。
