MongoDB 6.0 在事务协调器的通信路径上实施了一系列针对性优化：默认启用紧凑心跳机制，采用分片本地缓存加异步刷盘替代 config.transactions 全局锁，事务超时时间也从 60 秒缩短至 30 秒，同时需要协同调整 WiredTiger 缓存与驱逐参数以避免 WT_ROLLBACK。这些改动看似细微，但实际效果非常直接——跨分片事务的“卡顿感”明显降低，尤其在频繁开启和提交短事务的场景下，延迟更加可控，显著提升了 MongoDB 6.0 事务性能。
事务协调器通信路径变轻了
MongoDB 6.0 并未重写两阶段提交（2PC）协议，但在协调器与分片节点之间的心跳及元数据同步上做了大量精简。默认启用了更为紧凑的 transaction heartbeat 机制，有效缩短了锁的持有时间；事务状态更新不再强依赖 config.transactions 集合的全局锁，而是换用分片本地缓存配合异步刷盘。这样一来，跨分片事务的“卡顿感”显著下降，尤其在频繁开启和提交短事务的场景下，延迟表现更加稳定可控，这是 MongoDB 6.0 事务优化的重要亮点之一。
事务超时时间默认缩短到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 仍被明确禁止
虽然 6.0 优化了事务协调链路，但跨分片 $lookup 依然被明确禁止。即便目标集合未分片，只要事务内使用了 $lookup 且涉及分片集群，就会报 TransactionNotSupportedOnShardedCollection 错误。这不是 bug，而是设计限制——6.0 的优化聚焦于事务协调链路，并未改动聚合引擎对事务上下文的校验逻辑。如果业务确实需要关联查询，得拆成两步：先查主表 ID，再用这些 ID 批量查副表，从而绕开事务内的聚合操作。
总的来说，事务性能瓶颈从来不在“能不能跨分片”，而在于 WiredTiger 内存压力、oplog 吞吐节奏和锁粒度。6.0 的改动让事务“更快失败”或“更快完成”，但并未改变它不适合高频更新的本质。真正要压榨并发，还是得盯着 wiredTiger.cache 状态、oplogSizeMB 和分片键选择，别指望事务本身能带来质的飞跃，MongoDB 6.0 事务优化只是让现有机制更高效。
