跨分片事务无法优化，必须规避：事务操作须命中单一分片，查询条件需含分片键完整前缀，禁用$or、$in等不确定路由操作，且必须显式设置readConcern: "snapshot"并启用majority读关注。
跨分片事务本质是协调开销，不是慢，是必须绕开
跨分片事务在 MongoDB 分片集群中无法真正“优化”，它依赖 mongos 启动两阶段提交（2PC），全程锁定配置服务器元数据，并等待所有分片响应。任意一个分片延迟、网络抖动或副本集状态异常，整个事务就卡在 awaitingResponse 状态。监控上看，currentOp().secs_running 明显偏高，但 serverStatus().metrics.operation.write.conflicts 几乎不涨——这不是锁冲突，是分布式协调链路本身不可缩放。
确保所有事务操作命中单一分片的硬性条件
这是唯一落地有效的规避方式，不是建议，是前提。mongos 只有能**精确推导出目标 chunk 所在分片**，才不会广播请求。
- 事务内所有
find、updateOne、deleteOne的查询条件，必须包含分片键（shard key）的完整前缀。例如分片键为{orgId: 1, createdAt: -1}，则{orgId: "abc123"}合法，{createdAt: {$gt: ISODate("2026-01-01")}}不合法 - 禁用任何导致路由不确定的操作：
$or、$in（含多个值）、$regex、$text。mongos 无法计算范围时，会把请求发给所有分片 - 写操作必须显式携带分片键字段，否则 mongos 无法定位分片，直接报错
Location40587 - 避免使用哈希分片 + 非 _id 字段作为查询条件——哈希值无法做范围推导，容易误判为需广播
事务启动时必须带 readConcern: "snapshot"
这不是可选项，是分片环境下事务能执行的前提。缺了它，哪怕只读不写，Node.js 驱动（4.13+）、Python PyMongo（4.7+）等也会在元数据读取阶段失败，报错 Read concern 'snapshot' is not available for this operation。
- 必须在
session.startTransaction()里传入，不能在单个操作中加：session.startTransaction({ readConcern: { level: "snapshot" } }) - 如果事务里混用了
readPreference: "secondary"，readConcern: "snapshot"会被静默忽略，降级为local，失去一致性保证 - 确认所有分片和 config server 的
replication.enableMajorityReadConcern已开启，否则 snapshot 不可用
真正难的不是写对语法，而是让数据模型从一开始就排除跨分片场景
业务上需要强一致的关联数据（比如订单 + 订单明细 + 用户账户），不能靠事务去“兜底”，而应在设计阶段就绑定它们的物理位置。例如：把 userId 作为分片键前缀，让同一用户的全部相关文档天然落在同一分片；或用 zone + tag-aware sharding 强制某类集合只存于指定分片组。一旦上线后发现大量跨分片事务日志，说明分片键已成瓶颈，重构成本远高于应用层改用最终一致性模式（如消息队列 + 幂等更新）。
