MongoDB 6.0版本事务功能优化点有哪些？

MongoDB 6.0事务协调器通信路径变轻了：启用紧凑心跳机制、改用分片本地缓存+异步刷盘替代config.transactions全局锁，transactionLifetimeLimitSeconds默认从60秒降至30秒，并需协同调优wiredTigerCacheSizeGB与eviction参数以避免WT_ROLLBACK。

事务协调器通信路径变轻了

MongoDB 6.0 没有重写两阶段提交（2PC）协议，但把协调器和分片节点之间的心跳与元数据同步逻辑做了精简：默认启用更紧凑的 transaction heartbeat 机制，减少锁持有时间；事务状态更新不再强依赖 config.transactions 集合的全局锁，改用分片本地缓存 + 异步刷盘。这意味着跨分片事务的“卡顿感”下降，尤其在频繁开启/提交短事务的场景下，延迟更可控。

事务超时时间默认缩短到30秒

transactionLifetimeLimitSeconds 参数从 4.2–5.x 的 60 秒降为 30 秒，直接降低长事务阻塞其他操作的概率。这个值可动态调整：
db.adminCommand({ "setParameter": 1, "transactionLifetimeLimitSeconds": 15 })，但低于 10 秒容易触发 TransactionTooOld 错误——不是所有业务都能承受这么激进的收紧，得结合应用层事务平均耗时来判断。

WiredTiger 缓存配置对事务吞吐影响更敏感

事务期间所有修改都暂存在 WiredTiger 内存页中，wiredTigerCacheSizeGB 设置不当会立刻暴露问题：
• 默认值（物理内存 50%）在高并发事务下常不够用，实测 64GB 服务器设为 42GB 比默认 32GB 提升约 22% TPS；
• 必须同步调优 eviction_target（默认 80%）和 eviction_trigger（默认 90%），过高会提前淘汰页、增加磁盘压力，过低则堆积脏页，可能引发 WT_ROLLBACK 或 WT_DEADLOCK；
• 验证是否健康，看 db.serverStatus().wiredTiger.cache 中 pages evicted by application threads 是否持续增长。

跨分片 $lookup 仍被明确禁止

哪怕目标集合未分片，只要事务内用了 $lookup 且涉及分片集群，就会报 TransactionNotSupportedOnShardedCollection。这不是 bug，是设计限制：6.0 的优化聚焦于事务协调链路，没动聚合引擎对事务上下文的校验逻辑。如果业务真需要关联查询，得拆成两步——先查主表 ID，再用这些 ID 批量查副表，绕开事务内聚合。

事务性能瓶颈从来不在“能不能跨分片”，而在 WiredTiger 内存压力、oplog 吞吐节奏和锁粒度。6.0 的改动让事务“更快失败”或“更快完成”，但没改变它不适合高频更新的本质。真正要压榨并发，得盯着 wiredTiger.cache 状态、oplogSizeMB 和分片键选择，而不是指望事务本身提速。