MongoDB跨文档事务显著拖慢写入性能，实测耗时高4–7倍，超30秒易触发TransactionTooLargeForCache错误；分片集群下限制多且不可靠；嵌入式建模和最终一致性才是更优解。
跨文档事务会显著拖慢写入性能
MongoDB 的事务不是轻量级操作，它依赖副本集的 oplog 多数写入、两阶段提交和会话锁机制。实测中，一个包含 3 次 updateOne 的跨文档事务，在副本集上平均耗时比等价的单文档更新高 4–7 倍；若事务持续超过 30 秒，TransactionTooLargeForCache 错误概率陡增——这个错误从 MongoDB 6.2 起不再自动重试，直接失败。
常见踩坑点：
- 在高并发下单接口里对
orders、inventory、user_balance三张集合做事务更新，QPS 从 1200+ 掉到 200 以下 - 事务内混用
find+update，触发快照读开销，进一步延长持有锁时间 - 没设
maxTimeMS，个别慢查询卡住整个会话，导致后续请求排队超时
分片集群下事务支持受限且不可靠
跨分片事务从 MongoDB 4.2 开始支持，但仅限于“所有参与集合都位于同一分片”或“通过 shard key 能路由到相同分片”的场景。一旦涉及广播式写（比如按 user_id 分片，却要同时更新 orders 和 logs，而这两者 shard key 不一致），事务会直接报错 CannotSatisfyWriteConcern 或静默降级为非事务执行。
更现实的问题是运维层面：
- 分片集群必须启用
featureCompatibilityVersion: "6.0"或更高，否则事务命令被拒绝 - mongos 节点需配置
transactionLifetimeLimitSeconds，默认 60 秒，但很多业务逻辑实际需要 90–120 秒，不调就崩 - shard key 设计若未提前对齐事务边界，上线后几乎无法重构——改
shard key需停服迁移
嵌入式模型通常能绕过事务需求
多数所谓“必须跨文档”的场景，其实源于建模时过早拆分。比如电商订单，把 order、order_items、shipping_address 拆成三张集合，看似规范，实则放弃 MongoDB 最大优势。正确做法是把高频共查、强一致性要求的数据打平进一个文档：
{ "_id": "...", "order_no": "ORD-20261020-001", "status": "paid", "items": [ { "sku": "A100", "qty": 2, "price": 89.9 }, ... ], "shipping": { "name": "张三", "phone": "138...", "addr": "..." }, "payment": { "method": "alipay", "tx_id": "20261020..." } }
这样一次 updateOne 就完成状态推进，天然原子，无需事务。验证点很直接：如果 90% 的读请求都要 $lookup 或应用层 join，那大概率该合并了。
事务掩盖了数据模型腐化的信号
当团队习惯用事务兜底，就会放任文档粒度越切越细、集合之间耦合越来越隐晦。结果是：代码里满是 session 传递、异常分支堆叠、测试用例难覆盖中间态；线上一出问题，回溯成本远高于重构模型本身。
真正值得上事务的场景极少，比如：
- 银行级资金划转（账户 A 扣款 + 账户 B 入账 + 生成交易流水，三者缺一不可）
- 审批流中“提交→锁定资源→生成工单→通知负责人”，任意环节失败必须全撤
- 跨系统同步配置，要求本地 DB 与远端 API 状态严格一致
其余多数情况，要么用单文档嵌套解决，要么接受最终一致性（如发 MQ 异步补偿），而不是默认打开事务开关。最容易被忽略的一点是：startSession() 后忘记 abortTransaction() 或没包 try/catch，会导致会话泄漏，积压到一定数量直接阻塞新事务创建——这个故障现象不像报错那么明显，但会让整个集群写入缓慢下来。
