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.cache 状态、oplogSizeMB 和分片键选择，而不是指望事务本身提速。
