跨分片事务触发2PC和文档级长锁，因mongos需协调多分片执行prepare/commit，各分片文档被WiredTiger持writeLock直至事务终结；实测prepare阶段耗时超60%，RTT>15ms时事务可能卡顿200ms+。
跨分片事务无法被“设计掉”，但可以被完全规避——只要所有操作落在同一分片上，mongos 就不会触发两阶段提交（2PC），锁冲突和 prepare 阶段延迟自然消失。
为什么跨分片路由会触发 2PC 和文档级长锁？
当一个事务里涉及的文档被路由到不同分片（比如 order 写入 shard01，order_items 写入 shard02），mongos 必须协调所有参与分片：先发 prepare 请求、等全部响应、再统一 commit 或 abort。整个过程中，每个分片上的目标文档都会被 WiredTiger 持有 writeLock，直到事务终结。实测显示，prepare 阶段耗时常占整个事务 60% 以上，尤其在网络 RTT > 15ms 时，单次跨分片事务可能卡住 200ms+。
确保事务本地化的三个硬性条件
必须同时满足以下三点，事务才不会跨分片：
- 所有集合使用**相同的分片键字段名**（如都用
order_id） - 所有相关文档的分片键值**完全一致**（如订单和其子项都用同一个
order_id） - 分片键值在写入前已知，且不依赖事务内其他操作生成（例如不能靠
$inc或$push动态构造）
不满足任一条件，mongos 会在 session.startTransaction() 后首次写入时直接抛出 IllegalOperation: Cannot perform transaction with operations on multiple shards。
分片键设计不当的典型翻车现场
常见错误不是“没设分片键”，而是键选得让业务天然跨分片：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 用
user_id分片用户表，却用order_id分片订单表 → 即使是同一用户的订单，user_id和order_id值无关，必然散落多分片 - 用时间戳类字段（如
created_at）作分片键 → 新订单全挤在最新 chunk，旧 chunk 空转，均衡器疯狂迁移，间接导致关联数据被拆散 - 分片键基数过低（如只有
"paid"/"unpaid"两个值）→ 所有订单只落在 1～2 个分片，事务看似“不跨”，实则引发严重热点和锁排队
验证是否真本地化：开启慢日志后执行事务，检查 db.currentOp({ "secs_running": { "$gt": 1 } }) 输出里的 shard 字段是否只出现一个值；或直接查 sh.status() 确认目标 order_id 对应的 chunk 是否全部归属同一 shard。
事务外补位：当强一致性确实绕不开跨分片
如果业务逻辑注定要更新多个分片上的实体（比如支付成功需同步扣减库存 + 更新物流状态），别硬扛事务，改用最终一致模式：
- 第一步：在本地分片完成核心写入（如订单状态改为
"paid"），并记录一条outbox消息 - 第二步：由独立消费者拉取
outbox，调用幂等接口更新库存服务（HTTP/gRPC）和物流服务 - 第三步：失败时重试 + 死信告警，不阻塞主流程
这种模式下，MongoDB 只承担“单分片原子写入”，彻底甩开 2PC 开销；而跨服务协调交给消息中间件（如 Kafka/RocketMQ）和业务层幂等控制——这比在数据库层死磕分布式事务更可控、更可观测。
真正难的不是写事务代码，而是判断哪些地方根本不需要事务：嵌入式文档能解决的，就别拆集合；单文档原子操作能覆盖的，就别先查再改；分片键设计没对齐业务访问模式的，加再多索引也救不了事务性能。
