scatter-gather（广播查询）会导致查询变慢，因其将请求发往所有分片，延迟取决于最慢分片；可通过explain("executionstats")查看nshards>1及各分片executiontimemillisestimate非零来确认，常见原因包括未带分片键完整前缀、使用不支持路由的操作符或分片键类型不一致。
查询变慢大概率是发到了所有分片，而不是你预期的单个分片——这叫 Scatter-Gather（广播查询），它会让延迟直接卡在最慢那个分片上，不是平均值。
怎么确认是不是 Scatter-Gather 导致的慢查询
别猜，用 explain("executionStats") 看真实执行路径：
复制AI写代码db.users.explain("executionStats").find({ region: "cn", userId: "u123" })
重点盯两个字段：
-
nShards：如果大于 1，且你本意是查单分片，基本坐实了广播 -
executionStages.shards列表里每个分片的executionTimeMillisEstimate：多个分片都非零，说明真被广播了
注意：mongos 日志里的耗时是总耗时（含网络、协调、合并），不能反映单分片真实执行时间；要定位路由问题，必须看 explain 返回的分片级指标。
一款AI工具，主要用于在持久tmux会话中运行AI编码代理(Codex、Claude Code)，使用Ralph重试循环和完成钩子处理多步骤编码任务，适合需要提升相关任务效率的用户。
Scatter-Gather 常见触发原因
Targeted Query 失效，核心就一条：查询条件无法唯一确定一个分片。常见踩坑点：
- 查询没带分片键或其完整前缀 —— 比如分片键是
{region: 1, userId: 1}，但只查{userId: "u123"}，mongos就没法推导目标分片 - 用了不支持路由的操作符：
$ne、$not、$regex（非前缀匹配）、$where，或者聚合管道里有$lookup/$facet等阶段 - 分片键字段类型不一致 —— 比如
region有的存"cn"（string），有的存ObjectId("...")，哈希计算错位，路由直接失效
聚合查询如何避免广播
聚合想走 Targeted，比普通查询更敏感，必须满足：
-
$match阶段放在最外层，且条件中包含分片键完整前缀 - 不能被
$or包裹 ——$or会让mongos放弃路由推导 - 如果要用
$lookup，被联查的集合也得是分片集合，且localField/foreignField要能对齐分片逻辑，否则照样广播
示例安全写法：db.orders.aggregate([ { $match: { region: "cn", userId: "u123" } }, { $group: { _id: "$status", count: { $sum: 1 } } } ])
广播查询不是 bug，但得知道它什么时候该出现
全量统计（db.users.countDocuments({})）、按非分片键字段查（{email: "a@b.com"}）、跨区域拉取数据 —— 这些场景广播是合理甚至必要的。这时候瓶颈不在路由逻辑，而在各分片响应时间差异和 mongos 合并开销。
真正危险的是：你以为查的是单分片，结果悄悄广播了。这种情况往往伴随分片键设计不合理（比如用 createdAt 当分片键，导致范围查询必扫多片），或者业务查询长期没校验 explain 输出。
