MongoDB高并发写入时，复合索引设计不当会导致写入延迟飙升、写锁排队及复制延迟；单集合索引超7个使吞吐降30%以上，writeConflicts占比＞0.8%表明锁争用严重；需通过explain、profiler和前缀原则识别并删除冗余索引。
在高并发写入场景下，MongoDB每新增一条文档，所有相关索引都必须同步更新；若复合索引设计不当，写入延迟可能从毫秒级飙升至数百毫秒，甚至触发主节点写锁排队或从节点复制延迟告警。
确认当前写入负载与索引数量关系
进入MongoDB Shell，执行 db.getCollectionNames().forEach(c => print(c + ": " + db[c].getIndexes().length))，查看每个集合的索引总数。重点关注写入频繁但索引数超过5个的集合——【单集合索引数＞7时，写入吞吐通常下降30%以上】。
运行 db.serverStatus().metrics.operation.write，检查 total 与 writeConflicts 比值。若 writeConflicts 占比持续高于 0.8%，说明 WiredTiger 文档级锁已出现明显争用，复合索引可能加剧该问题。
量化单条写入的索引维护开销
方法一：使用 explain("executionStats") 观察插入语句的索引更新耗时
执行 db.orders.explain("executionStats").insertOne({user_id:123, status:"shipped", created_at:new Date(), amount:99.9})，重点提取 executionTimeMillis 和 wireVersion 字段值。对比无索引集合的相同操作耗时，差值即为当前索引体系带来的额外开销。
方法二：启用数据库分析器捕获真实写入路径
先执行 db.setProfilingLevel(2, {slowms:1})，再持续写入1000条测试数据，最后运行 db.system.profile.find({"op":"insert"}).sort({"millis":-1}).limit(5)。观察 top 5 耗时记录中 keysExamined 总和是否显著高于 nInserted——若前者是后者的8倍以上，表明多个复合索引正在重复扫描键值。
识别冗余复合索引的低效字段组合
第一步：导出全部复合索引定义
执行 db.runCommand({listIndexes:"orders"})，筛选出 key 字段含多个键的索引，保存为 JSON 列表。
第二步：按最左前缀原则合并去重
对每个索引 key（如 {"a":1,"b":1,"c":1}），生成其所有合法前缀：{"a":1}、{"a":1,"b":1}、{"a":1,"b":1,"c":1}。将所有前缀汇总后去重，得到最小必需索引集。
第三步：标记可删除的冗余索引
遍历原始索引列表，若某索引的完整 key 已完全包含在最小必需索引集中（例如已有 {"a":1,"b":1,"c":1}，则 {"a":1,"b":1} 即为冗余），【直接删除该索引前务必先禁用对应业务查询路径，否则将触发全集合扫描】。
模拟高频更新对复合索引的冲击
使用 mongostat 工具实时观测内存与锁竞争指标：
在终端执行 mongostat -h localhost:27017 --discover -n 30 1，重点关注 netIn、netOut、locked % 和 qr|qw 四列。当 qr|qw 中 qw 值持续 ≥3 且 locked % ＞15%，说明写队列已在积压。
此时向目标集合发送 1000 次 updateOne 请求（仅更新一个非索引字段，如 { $set: { updated_at: new Date() } }），观察 locked % 是否进一步跃升。若上升幅度超 20%，证明现有复合索引结构已无法承受该写入密度。
