事务内操作缺失分片键会导致mongos广播请求至所有分片，因路由层无法定位目标shard；即使单文档更新，只要filter未包含有效分片键字段（含null或$exists:false），即触发广播，显著降低性能并增加失败风险。
事务本身不“触发广播”，但当事务内查询或更新操作无法被 mongos 正确路由到目标分片时，底层就会退化为广播行为——而分片键字段缺失，正是最直接的路由失效原因。
分片键缺失导致事务内操作失去目标分片
在分片集群中，mongos 路由决策完全依赖分片键值计算哈希或范围定位。如果事务中任意一个 find、updateOne、deleteOne 等操作的筛选条件里没有提供有效的分片键字段（包括值为 null 或字段根本不存在），mongos 就无法推导出该操作应发往哪个 shard。
- 即使整个事务只改一条文档，只要
{_id: "x"}不是分片键，且你没显式带上分片键字段，mongos 仍会把该updateOne请求发给所有 shard - 事务的原子性由协调者（coordinator shard）保障，但“发送到哪”这件事不由事务逻辑控制，而是由 mongos 的路由层在请求发出前就决定的
- 缺失分片键的文档实际被路由到
minKey到null的 chunk，但这个信息对 mongos 来说不可用于反向构造路由条件——它只在写入时生效，不参与读/更新的查询路由
为什么 $exists: false 或 {shardKey: null} 也无法定向事务操作？
看似带了分片键字段，但这类条件在事务上下文中仍大概率导致广播，原因有二：
-
{shardKey: null}在多数驱动中会被序列化为 BSONNull类型，而分片键若实际存储的是缺失字段（即字段根本不存在），其内部表示是 “field not present”，与null值语义不同；mongos 对二者不做等价处理 -
{shardKey: {$exists: false}}属于非路由友好操作符，和$ne、$regex一样，会直接禁用分片路由推导——这是 MongoDB 的硬性限制，不是 bug - 哪怕你在事务里先
findOne({shardKey: null})拿到 _id，再用这个 _id 去updateOne，只要 update 的 filter 没带分片键，依然广播
复合分片键下“部分字段缺失”等于全缺失
假设分片键是 {tenantId: 1, userId: 1}，以下写法全部无效：
-
{userId: "u123"}—— 缺少前缀字段tenantId，无法路由 -
{tenantId: null, userId: "u123"}——tenantId值为null，但实际 chunk 分布中该字段是缺失而非null，哈希结果不匹配 -
{tenantId: {$exists: false}, userId: "u123"}——$exists直接关闭路由能力
真正有效的最小条件是 {tenantId: "t1"} 或 {tenantId: "t1", userId: "u123"}，且值类型必须与集合中真实存储一致（比如不能把 string 当 ObjectId 传）。
事务里补分片键字段要格外小心
想在事务中用 updateOne 给缺失分片键的文档补值？可以，但必须满足两个前提：
- update 的 filter 必须能定向——也就是说，你得先通过其他方式（比如唯一索引字段 + 已知值）精准定位到那条文档，且该字段不能是分片键本身（否则又绕回原问题）
- update 的
$set动作里设置的分片键字段值，必须符合该分片键的分布预期；如果新值导致文档需要迁移到其他 shard，而当前事务跨分片，MongoDB 会拒绝该更新（报错Cannot modify the shard key's value或类似）
最稳妥的做法是：先用非事务操作（如带 _id 的单点 update）补全分片键，确认文档已落定到目标 shard 后，再在事务中使用它——因为事务内的路由判断发生在执行前，不会动态重试或重定向。
真正容易被忽略的一点是：事务的性能损耗不仅来自跨分片协调，更来自隐式广播。一次看似简单的 updateOne，如果 filter 没带分片键，它会在每个 shard 上都执行一遍，再由 mongos 合并结果——这比单分片事务慢数倍，且可能因某一分片临时不可用导致整个事务中止。
