MongoDB 6.0集群事务不提升单点吞吐，仅解决跨分片一致性；优化聚焦协调器通信、缩短默认事务时限、降低config集合锁依赖；WiredTiger缓存配置与eviction参数协同影响并发性能；高并发需规避跨分片$lookup、重复写冲突及oplog过小导致同步中断。

MongoDB 6.0 的集群范围事务在高并发写入场景下**仍不推荐作为高频更新的主路径**，它解决的是“跨分片一致性”问题，而非提升单点吞吐。真正影响并发性能的，是 WiredTiger 存储引擎层的锁粒度、oplog 写入节奏和事务内存限制。

为什么 multi-document transaction 在分片集群中变快了

6.0 并没有重写事务协议，而是优化了协调器（transaction coordinator）与分片节点间的通信路径：

• 引入更轻量的两阶段提交（2PC）心跳机制，减少锁持有时间；
• 支持 transactionLifetimeLimitSeconds 动态调优，默认从 60 秒缩短为 30 秒，避免长事务阻塞其他操作；
• 事务元数据不再强依赖 config.transactions 集合的全局锁，改用分片本地缓存 + 异步刷盘；
• 注意：db.adminCommand({ "setParameter": 1, "transactionLifetimeLimitSeconds": 15 }) 可临时收紧，但低于 10 秒易触发 TransactionTooOld 错误。

wiredTigerCacheSizeGB 设置不当会直接拖垮事务并发度

事务执行期间所有修改都暂存在 WiredTiger 的内存页缓存中，若缓存不足，会触发频繁的 page eviction 和磁盘刷写，导致 WT_ROLLBACK 或 WT_DEADLOCK 报错：

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

• 默认值是物理内存的 50%，但在高事务负载下，建议设为可用内存的 60%～70%，留出空间给操作系统文件缓存；
• 实测：64GB 服务器上，cacheSizeGB: 42 比默认 32GB 提升约 22% 的事务吞吐（TPS）；
• 不能只看 cacheSizeGB，还要配合 eviction_target（默认 80%）和 eviction_trigger（默认 90%），过高会提前触发淘汰，过低则延迟写压力；
• 验证命令：db.serverStatus().wiredTiger.cache 中关注 bytes currently in the cache 和 pages evicted by application threads 是否持续增长。

高并发事务必须绕开的三个坑

这些不是 6.0 新增的问题，但在新版本中因默认行为更激进而更容易暴露：

• 事务内不能使用 $lookup 跨分片聚合 —— 会报 TransactionNotSupportedOnShardedCollection，即使目标集合未分片也不行；
• 事务中对同一文档的多次 $set 更新，不会合并为一次写入，WiredTiger 仍按顺序加锁，容易触发 WriteConflict；
• 启用 readConcern: "snapshot" 后，事务会延长 oplog 保留窗口，若 oplog 太小（如 oplogSizeMB: 1024），可能造成从节点同步中断或全量重同步。

真正决定高并发写入能力的，从来不是事务 API 是否支持跨分片，而是你是否让每个分片上的单节点写入尽可能“窄”——字段更新最小化、索引覆盖最大化、事务生命周期压到最短。6.0 的改进只是让这个过程更可控，而不是让它变“快”。