是跨分片排序导致CPU飙升：日志查“sort”和“shardVersion”，currentOp筛含“SHARD_MERGE”与“SORT”的长时query，explain显示“SHARD_MERGE”下有“SORT”即确认。
mongos CPU飙升时怎么快速定位是不是跨分片排序惹的祸
直接看 mongos 日志里有没有高频出现 "sort" : { ... }, "shardVersion" 或带 "$sort" 的聚合 pipeline；更准的是连上 mongos 执行 db.currentOp({ "secs_running": { "$gt": 5 }, "active": true })，重点筛 "operation": "query" 且 "planSummary" 含 "SHARD_MERGE" 和 "SORT" 的操作。这类请求必须拉所有分片数据到 mongos 再排序，CPU 和内存双吃紧。
- 跨分片
$sort+$skip/$limit尤其危险——每个分片都得返回全量中间结果 -
explain("executionStats")在mongos上跑，如果"executionStages.type"是"SHARD_MERGE"且子节点有"SORT"，基本坐实 - 注意区分：单分片内排序（
"IXSCAN" → "SORT"）不经过mongos，不占它 CPU
聚合管道里哪些操作会触发 mongos 级内存聚合
不是所有聚合都会压垮 mongos，但以下几种组合会让它变成单点瓶颈：
-
$group且_id不是分片键或不含分片键前缀——无法下推，所有文档拉到mongos再分组 -
$lookup目标集合未开启allowDiskUse: true且结果集大，mongos内存溢出后直接 OOM -
$facet每个分支都跨分片执行，再由mongos合并，内存占用是各分支之和 - 哪怕只有
$project+$match，如果前面步骤已导致大量数据汇集到mongos，后续操作也会卡住
关键判断依据：查 currentOp 输出里的 "memUsageBytes" 字段，超过 500MB 就该警惕了。
绕过 mongos 排序/聚合的实操方案
核心思路是让计算尽量落在分片上，而不是让 mongos 当“搬运工+计算器”：
- 排序必须用分片键或其前缀做条件：比如分片键是
{ region: 1, ts: 1 }，那就用{ region: "cn", ts: { "$gt": ISODate(...) } }+.sort({ ts: -1 })，这样排序能下推到每个分片 - 聚合改写：把
$group拆成两阶段——先在各分片用分片键做局部$group（加"allowDiskUse": true），再用mongos做最终合并（此时数据量已大幅减少） - 用
db.collection.aggregate(..., { "allowDiskUse": true })强制启用磁盘，避免mongos内存爆掉；但注意这会慢，只是保命手段 - 临时禁用某些高开销功能：比如关掉
mongos的enableSharding相关统计收集（setParameter调整shardingStatisticsLogFrequencySecs）
为什么加索引有时也救不了 mongos 高 CPU
索引对分片内查询有效，但解决不了跨分片协调本身的开销。常见误判场景：
- 给非分片键字段建了索引，查询仍要 fan-out 到所有分片，
mongos得合并 N 份结果再排序——索引只加速了单分片扫描，不减少网络和内存压力 - 复合索引顺序没对齐分片键：比如分片键是
{ a: 1, b: 1 }，却建了{ b: 1, c: 1 }索引，根本无法用于路由，全表扫分片 -
mongos自身没有索引概念，它只转发、合并、排序；索引建在哪，只影响目标分片的执行效率
真正有效的优化永远从查询模式倒推分片键设计开始——如果业务绕不开跨分片排序，说明分片键可能选错了，这时候调优索引只是打补丁。
