跨分片事务强制触发两阶段提交（2PC），协调开销随分片数指数级放大，导致延迟激增、锁升级为全局级、冲突转移至mongos协调队列，根本原因在于逻辑事务边界与物理分片边界错位。
跨分片事务触发两阶段提交，协调开销指数级放大
分片集群中，只要事务涉及多个分片（比如查询条件不含分片键、或更新分散在不同 shard 的文档），mongos 就必须启动两阶段提交（2PC）：先在所有参与分片上预写日志、加锁、准备提交；再统一协调 commit 或 abort。这个过程不是线性增长，而是随分片数增加呈指数级上升——每多一个分片，协调消息往返次数、状态同步延迟、失败回滚复杂度都跳变。
常见错误模式：session.startTransaction() 后执行 db.orders.updateMany({status: "pending"}, {...})，但 orders 集合按 user_id 分片，而该语句没带 user_id，结果广播到全部 8 个分片，2PC 协调耗时直接从 120ms 拉长到 2.3s。
- 用
db.currentOp({ "secs_running": { "$gt": 5 } })在 mongos 上查活跃操作，若看到type: "txnCoord"且secs_running > 3，基本就是 2PC 卡住了 - mongos 日志里频繁出现
"Waiting for majority commit point"或"aborting transaction due to coordinator timeout"是典型信号 - 不要依赖
maxTimeMS来“兜底”——它只在事务内命令执行时生效，2PC 协调阶段不计时
跨分片事务强制升级为全局锁协调，文档级锁失效
WiredTiger 默认的文档级锁，在跨分片事务中会退化为集合级甚至数据库级协调锁。因为 mongos 要保证原子性，必须在所有分片上锁定相关元数据（如 chunk range、shard version），同时防止其他事务修改同一逻辑范围的数据。这导致：同一时间只能有一个跨分片事务在协调，后续事务全排队等 txnCoord 锁释放。
现象是：db.serverStatus().metrics.operation.write.conflicts 突然飙升，但 wt_txn_update_conflict 反而下降——冲突不再发生在存储引擎层，而卡在 mongos 协调器队列里。
- 检查
sh.status()输出中各分片的chunks数量是否严重不均：如果某分片只有 2–3 个 chunk，却承担了 70% 的跨分片事务请求，说明分片键设计让多数事务被迫跨 shard - 事务内任何未命中索引的读（如
find({createdAt: {$lt: ...}})无分片键），都会让该分片升级为集合扫描，进一步拉长锁持有时间 - 避免在事务中调用
count()或distinct()——它们会触发全分片广播扫描，直接阻塞整个协调链路
transactionLifetimeLimitSeconds 不是超时熔断，而是被动拒绝点
transactionLifetimeLimitSeconds 默认 60 秒，但它不是定时器，而是 mongos 在每次收到 commitTransaction 或 abortTransaction 请求时才检查“事务已运行多久”。这意味着：事务可能卡在 HTTP 外部调用、循环写入、或网络抖动中长达数分钟，mongos 完全不干预，直到应用主动发 commit —— 此时才报错 TransactionTooOld。
这个机制容易掩盖真实瓶颈：你看到的是“事务超时”，实际是“事务早该在 3 秒内结束，却因设计缺陷拖了 47 秒”。
- 该参数必须在所有 mongos 实例的配置文件中静态设置：
sharding.transactionLifetimeLimitSeconds: 45，运行时db.adminCommand({setParameter:1, ...})无效 - 真正有效的防御在应用层：所有事务块必须包在
try/catch/finally中，finally里无条件调用session.abortTransaction() - 对含外部依赖的操作（如支付回调结果校验），必须前置完成并缓存结果，禁止在
session.startTransaction()和commit之间做任何阻塞 I/O
为什么拆成多个单分片事务反而更慢？
把一个跨分片事务硬拆成 N 个单分片事务（比如按 user_id % N 分组），看似规避了 2PC，实则引入新问题：每个子事务都要独立走完整事务生命周期（开启快照、加锁、WAL 写入、提交确认），而 WiredTiger 对短事务的快照创建/销毁开销敏感。实测显示，10 个 200ms 的单分片事务，总耗时比 1 个 800ms 的跨分片事务高 3.2 倍。
更糟的是，若这些子事务更新同一业务实体（如订单状态），应用层还得自己实现分布式幂等和最终一致性，复杂度远超原生事务。
- 优先用单文档原子操作替代事务：比如
findOneAndUpdate({orderId: "xxx", version: 1}, {$set: {status: "paid", version: 2}}, {upsert: false})，靠 version 字段防覆盖 - 对非强一致场景（如日志记录、统计埋点），改用
w: "majority"的单文档写 + 应用层异步补偿，吞吐可提升 5–8 倍 - 真需要跨分片原子性时，考虑将热点数据聚合到单一分片（如用
{tenantId: 1, _id: "hashed"}），而非强行跨 shard 分布
