跨分片事务不该发生，因其强制依赖mongos协调的两阶段提交，任意分片卡住即全链路阻塞，且config server成单点瓶颈，必须通过分片键设计和数据建模从源头规避。
跨分片事务在 MongoDB 分片集群中变慢，不是“能优化多少”的问题，而是它根本就**不该发生**——所有跨分片事务都必须规避。
为什么 mongos 要为每个跨分片事务启动两阶段提交
mongos 不是简单转发请求，它得当协调器：先向所有涉及分片发送 prepareTransaction，等全部响应 OK 后，再发 commitTransaction。任意一个分片卡住（网络抖动、负载高、副本集选举），整个事务就停在 awaitingResponse 状态。这不是查询慢，是分布式协调链路本身不可缩放。
-
explain("executionStats")在跨分片事务里基本没用——它只显示单分片的执行计划，完全不体现协调开销 - 监控时看
currentOp().secs_running会发现大量事务卡在 50+ 秒，但serverStatus().metrics.operation.write.conflicts却几乎不涨 - 事务超时默认 60 秒，但
maxTimeMS对协调阶段无效；真正生效的是连接池 timeout 或客户端中断
分片键设计错误导致路由不确定
只要查询条件不含分片键完整前缀，mongos 就无法确定目标分片，只能广播到所有分片——这等于主动制造跨分片事务。
- 分片键是
{orgId: 1, createdAt: -1}，则{orgId: "abc123"}安全，{createdAt: {$gt: ISODate()}}危险 - 事务内用
$or、$in（含多个值）、$regex（尤其无前缀如/abc$/）会让 mongos 失去路由能力 - 写操作不带分片键字段？直接报错
Location40587，连事务都启不起来
配置服务器参与元数据锁定带来额外延迟
每次跨分片事务，config server 都要参与锁管理：记录事务状态、维护活跃会话、校验分片拓扑。它不存业务数据，却是全局单点瓶颈。
- config server 副本集（CSRS）若出现延迟或主节点切换，所有跨分片事务都会排队等待
- 事务生命周期内，它持续持有元数据锁，阻塞
sh.moveChunk()、sh.splitAt()等运维操作 - 备份时若未停 balancer，
mongodump --oplog也无法保证跨分片一致性——各分片 oplog 时间点根本不同步
真正难的不是写对 session.startTransaction，而是让数据模型从一开始就排除跨分片场景
事务语法写对很容易，但让所有业务操作天然落在同一分片上，需要在设计阶段就收敛访问模式：比如用户、订单、日志都用 userId 作分片键前缀；计数器类更新改用 findOneAndUpdate 压缩为原子操作；高频关联数据强制物理聚簇。否则，任何“事后优化”都是在给分布式协调链路打补丁，越补越重。
