跨分片事务慢的根源在于分片拓扑与数据路由，而非驱动或代码：mongos 协调多分片二阶段提交导致延迟激增，复制延迟超2s会触发ReadConcernMajorityNotAvailableYet错误；需确保shard状态正常、复制延迟≤1s、避免arbiter参与事务；分片键设计决定是否跨分片，应使关联文档路由至同一shard；readConcern和writeConcern须传入withTransaction()而非单个操作；事务超时应通过拆分为幂等短事务解决，而非仅调大配置；失败后必须显式abortTransaction()。
跨分片事务慢，根本不是驱动或代码问题
慢的根源在分片拓扑和数据路由——事务延迟主要来自 mongos 协调多个分片的二阶段提交开销，而不是你写的 updateOne() 本身。一个涉及 3 个 shard 的事务，平均延迟可能比单分片高 5~10 倍；若其中某个 shard 复制延迟 >2s，readConcern: "snapshot" 就会卡住等待，最终触发 ReadConcernMajorityNotAvailableYet 错误。
实操建议：
- 用
sh.status()确认所有 shard 的state是1，且每个 shard 的rs.status().members至少含 3 个非 arbiter 节点 - 检查各 shard 的复制延迟：
db.printSlaveReplicationInfo()（在 primary 上执行），延迟 >1s 的节点要优先排查网络或磁盘 I/O - 避免在事务中读写带
arbiter的 replica set——哪怕只读一个字段，也会导致整个事务中止并报CannotSatisfyWriteConcern
分片键设计不当，会让事务“不得不跨分片”
事务是否跨分片，不取决于你写了几个 collection，而取决于这些文档的分片键值是否被路由到同一 shard。比如订单和订单项都用 orderId 作分片键，并确保二者存于同一数据库、使用相同哈希策略，那 98% 的操作其实只走单分片。
常见错误场景：
- 用户表按
userId分片，订单表却按createdAt分片 → 一笔下单+扣余额必然横跨至少 2 个 shard - 分片键含高基数但低选择性字段（如
createdAt的秒级时间戳），导致 chunk 拆分后写入严重倾斜，部分 shard 成为瓶颈 - 未启用
analyzeShardKey就上线：运行db.runCommand({ analyzeShardKey: "orders", key: { orderId: 1 } , readWriteDistribution: true })提前暴露写热点
session 和 readConcern 必须在 startTransaction 时传入
Node.js 驱动里最容易漏掉的是：把 readConcern: "snapshot" 放在单个 find() 里，而不是 session.startTransaction() 的参数中。这样事务能启动，但后续任意一次读操作都会直接报错 Read concern 'snapshot' is not available for this operation。
正确写法（Node.js）：
const session = client.startSession();
await session.withTransaction(
async () => {
await db.collection('orders').insertOne({ oid: 'O123' }, { session });
await db.collection('accounts').updateOne({ _id: 'U789' }, { $inc: { balance: -100 } }, { session });
},
{ readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } }
);
注意两点：
-
readConcern和writeConcern是withTransaction()的第二个参数，不是startTransaction()的参数（后者已废弃） - 所有操作必须显式传入
{ session }，漏掉任何一个，该操作就脱离事务上下文，变成普通非事务写 - C#/.NET 驱动同理：必须用
session.WithTransaction()包裹 database 实例，不能只靠session.StartTransaction()
事务超时和长流程不是调大 transactionLifetimeLimitSeconds 就能解决
默认 transactionLifetimeLimitSeconds=60，看似够用，但实际中很容易踩坑：比如事务内调用外部 HTTP 接口、或触发慢聚合查询，mongos 会在 60 秒后强制中止——而此时部分 shard 已提交，无法回滚，造成数据不一致。
更稳妥的做法：
- 把长流程拆成多个短事务，用幂等 ID + 状态字段（如
status: "pending" → "confirmed"）衔接 - 确需长事务时，不只是改 mongos 配置，还要同步调高客户端 socket timeout 和驱动重试策略
- 禁止在事务中执行
createCollection、dropDatabase或任何 DDL —— 连insert触发的隐式建集合都会报CommandNotSupportedInTransaction
真正容易被忽略的是：事务失败后，session 对象不会自动失效。如果没在 catch 块里显式调用 session.abortTransaction()，这个 session 可能被后续请求复用，导致意外行为。
