当业务流量飙升，MongoDB集群开始出现写入延迟飙升、索引争用、甚至OOM时，很多团队的第一反应是加节点、扩磁盘。但问题往往出在索引设计上——每个多余的索引都会让写入操作付出额外的B树维护代价。在高并发写入场景下，索引不仅是查询加速器，更是写入瓶颈放大器。本文将直奔核心，拆解索引设计如何影响写入性能，并给出从索引选择到系统参数调优的完整路径。
索引设计如何拖慢写入：先理解代价
MongoDB的写操作（insert、update、delete）每涉及一个索引，就需要在对应的B树中插入或更新键值对。WiredTiger引擎使用B+树，每个索引的写入都需要一次磁盘I/O（或缓存命中但依然消耗CPU）。如果一个集合有5个索引，单条文档写入意味着至少5次索引树操作。并发量上来后，索引树的叶子节点会被频繁分裂、合并，buffer pool压力骤增，最终产生写锁争用。
因此，高并发写入优化的第一原则是：索引数量最小化。不是所有查询都需要索引，只对涉及查询和排序的字段建索引，那些“可能用得上”的冗余索引一律删除。
索引类型选择：复合索引优于多个单字段索引
很多团队习惯为每个字段独立建索引，方便各种查询组合。但在高并发写入场景下，这种方法代价太高。假设有字段a、b、c各建单字段索引，那么写一条文档需要维护3棵B树；而建成一个复合索引{a:1, b:1, c:1}，只需要维护1棵B树，写入开销直接降低到1/3。同时，复合索引可以覆盖更多查询模式，例如查询条件匹配a、匹配a和b、匹配a、b和c。
复合索引的设计策略是遵守“ESR”（Equality, Sort, Range）原则：将等值查询字段放在最左，排序字段其次，范围查询字段最后。例如，查询用户ID（等值）并按时间排序（sort），再筛选时间在某个范围，索引应为{userId:1, timestamp:1}。这样B树能快速定位到用户ID对应的子树，再按时间有序读取，避免内存排序。
注意：复合索引无法支持不基于最左前缀的查询。如果你确实需要独立查询b字段，那么需要单独评估是否值得为其保留单字段索引。如果查询频率极低且可以接受全表扫描，就应删除该索引。
写入时如何避免索引膨胀：在模式设计层面控制
MongoDB的文档模型灵活，但高并发写入场景下，文档结构设计直接影响索引大小。每个索引条目包含字段值和文档位置（记录ID）。如果字段值很长（如URL、长字符串），索引条目就会变大，B树节点能容纳的条目减少，树高度增加，写入时I/O次数上升。
方案一：使用哈希索引。对于大且分布均匀的字段（如MD5值），哈希索引可以固定索引键长度，但只能支持等值查询，不支持范围查询和排序。方案二：对字段进行预压缩，如使用短ID代替长字符串，或在前端将长文本哈希为64位整数存储在文档中，再对该整数字段建索引。
另一个容易被忽视的点：数组字段上的多键索引（Multikey Index）。每个数组元素都会生成一条索引条目，如果一个文档的数组有100个元素，那么每次更新该文档时，多键索引需要维护100个条目。高并发写入时，这种放大效应非常恐怖。因此，尽量避免在频繁更新的数组字段上建索引，或者将数组拆分为子文档集合。
高并发写入调优：从WiredTiger缓存到操作技巧
2.1 调整WiredTiger存储引擎缓存
写操作需要将索引页加载到缓存中才能修改，缓存命中率直接决定写入延迟。默认WiredTiger缓存大小为（总内存-1GB）* 0.5 或 256MB中的较大值。对于写密集场景，建议增大缓存，使索引页和工作集常驻内存。可以通过mongod配置项 wiredTigerCacheSizeGB 设置，例如设定为物理内存的60%-80%，但需为操作系统和其他进程留足空间。
同时，关注 eviction_dirty_trigger 和 eviction_trigger 参数。默认当脏页面比例达到20%时开始淘汰，在高并发写入时可能过早触发，导致索引页频繁刷盘。可以适当提高脏页阈值，例如设置 wiredTiger.eviction=(dirty_trigger=30,trigger=95)，但注意不要超过内存上限，否则会OOM。
2.2 批量写入代替逐条写入
每次客户端发送一条写请求，MongoDB需要解析请求、获取锁、写日志、更新索引。将1000条文档打包成一次 insertMany 或 bulkWrite，可以显著减少网络往返和锁开销。批量大小建议在100-1000条之间，过大可能导致操作时间过长，阻塞其他连接。WiredTiger引擎在批量插入时还能利用B树批量写入优化，一次性将多条索引插入同一叶子节点，减少分裂次数。
2.3 写关注级别与Journaling的权衡
写关注（write concern）控制写入确认级别。如果业务允许少量数据丢失（例如日志、非关键指标），可将 w: 0 或 w: 1 配合 j: false，跳过Journal写入，减少每次写操作的一次fsync。但需要评估数据可靠性要求：j: true 保证断电后不丢数据，但每次写入要写Journal文件，延缓返回。在高并发写入且对持久性要求不高的场景（如实时排行榜），可以关闭Journal。
2.4 使用TTL索引自动清理过期数据
如果业务数据有时效性（如会话、临时消息），使用TTL索引让MongoDB后台自动删除过期文档。这比定期手动 deleteMany 效率高得多，因为TTL删除是批量的，且对写入影响较小。注意TTL索引不能建在频繁更新的字段上，否则每次更新会重置过期计算。
实战：一个高并发写入索引设计的完整案例
假设我们有一个用户行为日志集合，每天写入亿级文档，查询模式主要是按用户ID和时间范围查最近N条记录。原始设计：为userId、timestamp、actionType各建单字段索引，写入TPS约2万时延迟飙升至500ms。
第一步：删除actionType单字段索引（该字段查询频率极低且允许全表扫描）。第二步：用复合索引{userId:1, timestamp:-1}替换userId和timestamp的单字段索引。第三步：批量写入改为每1000条一次bulkWrite。第四步：内存充足时将WiredTiger缓存从默认4GB提升到32GB。调优后，同样硬件下写入TPS提升到8万，延迟稳定在10ms以下。
该案例说明：索引数量减少+复合索引+批量写入+缓存放大，四管齐下才能突破瓶颈。
索引维护工具与监控
日常运维中，使用 db.collection.stats() 查看索引大小、索引命中率（索引扫描次数 vs 文档扫描次数）。通过 serverStatus 中的 wiredTiger.concurrentTransactions 判断写并发是否触发了引擎排队。定期使用 explain() 审查慢查询是否走对了索引。
另一个实用技巧：利用 indexStats 聚合（db.collection.aggregate([{$indexStats:{}}])）查看每个索引的访问次数和操作类型，删除从未使用或极少使用的索引。
总结
MongoDB的高并发写入性能，七分在索引设计，三分在参数调优。核心原则是：用最少的索引满足查询需求，用复合索引合并单字段索引，用批量操作减少写入次数，用充足的缓存容纳索引工作集。每次调优前，先通过监控确认当前瓶颈是CPU、内存还是磁盘I/O，再有针对性地调整索引或引擎参数。记住：在写入环节，多一个索引就是多一重枷锁。
延伸阅读