跨分片事务比单副本集事务慢的根本原因是强制两阶段提交（2PC），需mongos协调所有shard，每轮通信增加至少2×RTT延迟，且涉及config server元数据校验、多shard快照维护及连接上下文重建，导致链路长、失败点多、延迟阶梯式恶化。
跨分片事务为什么比单副本集事务慢得多
根本原因不是“MongoDB不支持”，而是跨分片事务强制走两阶段提交（2PC），且每个阶段都需 mongos 协调所有参与 shard，每轮通信至少增加 2×RTT 延迟。单副本集事务只在本副本集内协调，而跨分片事务要串行或并行联系多个 shard、config server 和可能的其他 mongos，链路更长、失败点更多。
常见错误现象包括：Transaction is not in progress、context deadline exceeded、commit 阶段卡住超过 10 秒；用 db.currentOp({ "secs_running": { "$gt": 5 } }) 查到大量状态为 inMultiStatementTransaction 的长时操作。
- 跨分片事务必须等所有 shard 返回 prepare 成功，任一 shard 网络抖动或负载高，整个事务就卡住
- mongos 到每个 shard 的连接不是复用同一通道，每次 prepare/commit 都新建逻辑上下文，放大连接建立开销
- config server 参与元数据校验（如分片键合法性、事务唯一性），若 config 副本集同步延迟高，会拖慢整个事务启动
- WiredTiger 在每个 shard 上为事务单独维护快照，跨分片场景下内存和锁竞争更剧烈，eviction 更频繁
如何判断当前事务是否真的跨了分片
别只看代码里写了 session.start_transaction()，得确认实际写入是否落在多个 shard 上。MongoDB 不会在事务开启时立刻路由，而是在第一个写操作执行时才确定分片归属——如果所有写都在同一个 chunk 范围内，哪怕集群有 10 个 shard，它也只触达 1 个。
实操建议：
- 在事务内第一个写操作后，立即执行
db.runCommand({ "explain": { "update": "orders", "updates": [...] }, "verbosity": "executionStats" })，看shards字段是否列出多个 host - 启用 slow query 日志：设置
operationProfiling.mode: "slowOp"+operationProfiling.slowOpThresholdMs: 100，查system.profile中millis> 500 且shards数量 > 1 的记录 - 用
mongostat --host mongos-host:27017 -v观察netIn/netOut是否在事务期间突增，结合shard01/shard02等列确认多分片参与
transactionLifetimeLimitSeconds 设得太短是高频雷区
默认值 60 秒对跨分片事务几乎不够用。一次 prepare 就可能因网络排队、WiredTiger checkpoint、oplog 写入阻塞耗掉 8–12 秒；commit 阶段再叠加锁竞争，很容易超限。服务端主动 kill 后，客户端再 commit 就报 InvalidOperation 或连接中断。
调整方式必须在 mongod 启动参数或副本集配置中修改，不能靠驱动设置：
- 在每个 shard 的 mongod 启动命令加
--setParameter transactionLifetimeLimitSeconds=180 - 或用
rs.reconfig()更新副本集配置中的settings.transactionLifetimeLimitSeconds - 注意：该参数只作用于 shard 节点，mongos 和 config server 不生效
- 同时检查
socketTimeoutMS（PyMongo 默认 30000）和maxTimeMS（事务内单条操作）是否匹配，避免客户端先超时断连
真正能压降延迟的三个硬手段
优化 DNS、调大连接池、换 SSD 这些对跨分片事务效果有限——瓶颈不在单节点 IO，而在协调路径上的任意一环。真正有效的动作只有三个：
-
把事务限制在单分片内：设计分片键时确保业务强相关数据（如用户订单+订单项）落在同一 shard，用
shard key = { userId: 1 }而非{ orderId: 1 } -
禁用 majority writeConcern：跨分片事务默认要求
w: "majority"，改成w: 1可让 commit 阶段少等多数派落盘，但需接受短暂不一致风险 -
用
readConcern: "available"配合事务读：避免事务内读操作被本 shard 的 oplog 应用线程阻塞，尤其当 secondary 承担读流量时
跨分片事务的延迟不是线性增长，而是阶梯式恶化：RTT 从 3ms 升到 8ms，P99 延迟可能从 400ms 跳到 2.1s。问题往往不出现在代码里，而出现在分片键设计那一刻。
