MongoDB 4.2+分片集群支持跨分片多文档事务，但要求真实部署、所有shard为三节点副本集、mongos与驱动版本≥4.2、显式设置readConcern:"snapshot"、集合须预先创建并完成分片，且避免capped/system集合操作。
MongoDB 4.2+ 分片集群上能跑跨分片多文档事务，但前提是：你用的不是伪分片（比如单 mongos + 单 shard），也不是本地随便起的 mongod；必须是真实部署的分片集群，且所有 shard 都是副本集（不能是单节点），mongos 版本 ≥ 4.2，客户端驱动也得 ≥ 4.2。
确认分片集群状态是否满足事务前提
事务在分片集群上不是“开了分片就自动支持”，它对底层拓扑有硬性要求：
- 每个
shard必须是副本集（rs.status()中能看到多个成员），单节点 shard 会直接拒绝事务操作，报错类似Transaction numbers are only allowed on a replica set member or mongos -
config server必须是三节点副本集（csReplSet），不能是单节点或旧版的 standalone configdb -
mongos进程需连接到该 config server 副本集，且自身版本 ≥ 4.2 - 运行
sh.status()，输出中每个 shard 的state应为1（OK），且shardingVersion≥ 1
常见误判：用 Docker Compose 拉起一个 mongos + 一个 shard01（单 mongod），看似“分片”，实则不满足事务条件——事务请求会卡在 mongos 层，最终超时或报 NotMaster。
跨分片事务必须显式指定 session + readConcern: "snapshot"
分片环境下，事务默认读关注（readConcern）不生效，不手动设就会出问题：
- 没传
readConcern: "snapshot"就执行find()或countDocuments()→ 报错Read concern 'snapshot' is not available for this operation - 即使只写不读，某些 driver（如 Node.js 4.13+）在分片事务中也会隐式触发元数据读取，缺
readConcern仍会失败 - 必须在
session.startTransaction()时传入选项，而不是在单个操作里加：session.startTransaction({ readConcern: { level: "snapshot" } })
示例（Node.js）：
const session = client.startSession();
await session.withTransaction(async () => {
const db = client.db('finance');
// 跨分片：orders 在 shard A，accounts 在 shard B
await db.collection('orders').insertOne({ oid: 'O123', status: 'pending' }, { session });
await db.collection('accounts').updateOne({ _id: 'U789' }, { $inc: { balance: -100 } }, { session });
}, {
readConcern: { level: "snapshot" }, // ← 关键！必须在这里指定
writeConcern: { w: "majority" }
});跨集合事务不能隐式建集合，也不能操作 system.* 或 capped 集合
分片事务比副本集事务更严格，DDL 类行为基本被禁用：
- 事务内执行
insertOne()到一个**尚不存在的集合** → 直接报错NamespaceNotFound（分片事务不允许隐式建集合） - 试图对
system.users、config.*、local.*执行任何读写 →not authorized on config to execute command或not supported in sharded transactions - 操作
capped: true的集合（哪怕只是find()）→Transactions are not supported on capped collections - 集合必须已存在，且已在对应分片上完成分片（
sh.shardCollection()已执行），否则写入会路由失败
容易被忽略的一点：分片键选择会影响事务性能。如果两个集合的分片键完全不同（比如 orders 按 oid 分片，accounts 按 uid 分片），一次事务要协调所有 shard，延迟明显升高；尽量让强关联集合使用相同分片键或可推导的键（如 account_id 作为 orders 的前缀）。
事务超时与锁竞争在分片环境下更敏感
60 秒默认超时在分片场景下更容易触达，原因很实际：
- 每次操作需经
mongos→shard→primary多跳网络，RTT 累积；一次跨 3 个 shard 的 update 可能就耗掉 2–3 秒 - 锁粒度是“文档级”，但分片间协调靠两阶段提交（2PC），任一 shard 提交失败，整个事务 abort，且其他 shard 已持有的锁要等超时才释放
- 高并发下容易出现
WriteConflict，尤其当多个事务更新同一分片上的不同文档但共享部分索引键时（如都更新status字段，而该字段上有非唯一索引）
建议：在事务体内部避免复杂聚合、大范围 updateMany；用 explain("executionStats") 预查单条操作耗时；超时阈值可通过 maxTimeMS 在 startTransaction() 里调低（如 { maxTimeMS: 30000 }），早失败比卡住强。
