mongodb事务默认超时60秒，必须显式配置maxtimems避免被截断；5.0起对分片集群超时更敏感，且仅支持相同分片键的跨集合事务，4.4不支持分片事务。

事务超时时间必须显式配置，否则默认60秒太短

很多线上事务失败不是逻辑问题，而是被 maxTimeMS 或隐式超时截断。MongoDB 4.4 和 5.0 都默认事务最长运行60秒，但 5.0 开始对超时更敏感——尤其在分片集群中，跨分片协调延迟容易触达阈值。

实操建议：

• 所有 startTransaction() 调用必须传入 maxTimeMS，例如 session.startTransaction({ maxTimeMS: 30000 })
• 若业务操作涉及大量文档（如批量状态更新），建议按每100文档预留2秒估算，避免硬写60秒
• 4.4 中部分驱动（如早期 Node.js driver 3.x）不自动传递 maxTimeMS 到事务上下文，需手动注入
• 5.0+ 对超时响应更严格：一旦超时，会直接抛出 TransientTransactionError，而不是静默回滚

分片集群下事务支持差异决定选型底线

如果你用的是分片集群，4.4 和 5.0 的事务能力有本质区别：4.4 不支持分片集群上的多文档事务；5.0 支持，但有硬约束。

关键限制点：

• 5.0 分片事务仅允许写入「相同分片键」的多个集合——如果事务里同时更新 orders（分片键 userId）和 inventory（分片键 skuId），会直接报错 MultiShardTransactionInvalid
• 4.4 在分片集群上调用 startTransaction() 会成功，但后续任何写操作都失败，错误信息模糊（常为 NotMaster 或空响应），排查成本高
• 若你当前是副本集部署，且无近期分片计划，4.4 的事务已够用；一旦要上分片，5.0 是唯一可选版本

writeConcern 和 readConcern 在事务中行为不同

事务内 writeConcern 不再作用于单个操作，而是由事务 session 统一控制；但 readConcern 的级别直接影响快照可见性，4.4 与 5.0 默认值不同。

Cognitive Mill

一款面向视频内容分析和自动化处理的云平台，可利用AI分析视频素材并辅助生成预告片等内容。

下载

注意以下实际影响：

• 4.4 默认 readConcern: "local"，事务中读取可能看到未提交写入（仅限本节点），导致脏读风险
• 5.0 默认升为 readConcern: "snapshot"，保证事务内读取一致性视图，但要求 WiredTiger 存储引擎且 oplog size 足够大（否则触发 SnapshotUnavailable 错误）
• 显式设置 readConcern: "majority" 在 5.0 中会禁用 snapshot 隔离，降级为可重复读，性能略升但一致性减弱
• 事务外的读请求不受事务内 readConcern 影响，不要误以为设了就全局生效

驱动兼容性比版本号更关键

选 4.4 还是 5.0，最终取决于你用的 driver 是否真正适配——不是看 MongoDB 服务端版本，而是看 driver 对事务 API 的封装是否完整。

常见踩坑点：

• Node.js 的 mongodb@3.6（对应 4.4）不支持分片事务，即使服务端是 5.0 也无效；必须升级到 @4.0+
• Python PyMongo 3.12+ 才完整支持 5.0 的 shouldMultiDocTxnCreateCollectionAndIndexes 移除后的行为（即事务内建集合不再需要开关）
• Java Driver 4.3+ 才正确处理 5.0 删除的 cachePressureThreshold 参数残留配置，否则启动时报 Unknown server parameter
• 别只查 MongoDB 版本，先 run db.version() 和 db.runCommand({ connectionStatus: 1 }).authInfo.authenticatedUsers 确认实际运行模式（副本集/分片）、FCV（featureCompatibilityVersion）是否真为 "4.4" 或 "5.0"

事务配置不是版本切换开关，而是服务端能力、驱动实现、数据模型三者咬合的结果。最容易被忽略的是：分片键设计是否天然支持跨集合事务——这比选哪个版本更早决定你能不能用事务。