MongoDB分片集群跨分片事务不满足强原子性：各shard为自治副本集，无共享日志、锁或快照视图，依赖mongos协调的两阶段提交（prepare/commit），受config server写入延迟和最慢shard拖累，且需满足分片启用、WiredTiger引擎、majority读关注等硬性前提。
分片集群中各shard是自治副本集，没有共享日志或锁机制
副本集事务能靠WiredTiger的MVCC + oplog timestamp对齐实现原子性，是因为所有数据都在同一组节点上，写入可被统一时间戳标记、锁可本地协调。而分片集群里，每个shard都是独立运行的副本集，彼此不共享oplog、不互通锁状态、也不共用事务快照视图——这意味着没有任何一个节点天然知道其他shard是否已成功预提交。
这种物理隔离导致无法像单副本集那样“一步到位”提交：必须引入外部协调者（mongos）来统一询问、记录、裁定和广播，这就是两阶段提交不可绕开的根本原因。
prepareTransaction必须持久化到config server，这是副本集事务完全没有的路径
分片事务在准备阶段会向config.transactions集合写入事务元信息（包括参与者列表、状态"prepared"、timestamp等），这个写入本身就是一个副本集事务，且强制writeConcern: "majority"。一旦config server写入延迟或排队，整个事务就卡在prepare阶段，db.currentOp()里看到secs_running很低但客户端早已超时，就是这个环节在阻塞。
常见误判是以为卡在某个shard的本地操作，实际瓶颈常在config server的磁盘IO或选举震荡；可通过metrics.recordReplOplog突增确认。
commit阶段受最慢shard拖累，“木桶效应”明显
协调器（mongos）进入commit阶段前，必须收到所有shard返回的prepare成功响应；commit指令发出后，又必须等待全部shard返回commit完成。任意一个shard因GC暂停、网络抖动或磁盘慢，都会让整个事务RTT拉长——这不是协议设计缺陷，而是拓扑结构决定的刚性约束。
对比MySQL的2PC：它的redo log与binlog都在同一进程内协调，延迟在微秒级；MongoDB跨shard通信至少涉及3次以上网络往返，跨机房场景下单次prepareTransaction RTT常超40ms。
不满足两阶段提交前提条件时，事务会静默降级或直接报错
MongoDB分片事务对环境有硬性要求，缺一不可：
-
enableSharding必须为true，且所有shard和config server都运行WiredTiger引擎（MMAPv1完全不支持） -
replication.enableMajorityReadConcern必须开启，否则snapshot隔离级别不可用，事务会退化为local读，失去一致性保障 - 所有参与集合必须已启用分片（
sh.enableSharding("db")+sh.shardCollection("db.coll", {...})），未分片集合上的操作会被拒绝
最容易被忽略的是最后一点：开发者常在事务里混入未分片集合的insertOne或updateOne，错误信息可能是模糊的CommandNotSupported或NotSharded，而非明确提示“跨分片事务不允许操作非分片集合”。
