根本原因是分片无法本地排序，导致Mongos需全量拉取数据后内存排序；正确做法是建含分片键前缀的复合索引，确保各分片能独立排序后再归并。
分片集群里 sort() 慢，根本原因不是 Mongos 合并不够快，而是多数排序请求根本没走索引，被迫在每个分片上全量拉数据、再在 Mongos 内存里 merge —— 这种模式下数据量一过几百万，executionTimeMillis 就会指数级上涨。
为什么 Mongos 的 Merge Sort 不是性能瓶颈？
Mongos 本身不参与排序计算，只做结果归并：它从各分片拿到已按指定顺序排好序的游标（前提是分片能本地完成排序），然后用堆合并（heap merge）把多个有序流合并成一个有序流。这个过程开销很小。
- 真正卡住的是：分片无法本地排序，只能返回未排序的原始文档流，Mongos 被迫先收集全部结果再 sort —— 此时
sort()变成内存中全量排序，受internalQueryExecMaxBlockingSortBytes限制（默认 32MB） - 如果某个分片返回 100 万文档，而你只取前 20 条，但 Mongos 不知道，它仍得等所有分片发完才开始 merge
-
explain("executionStats")中若看到winningPlan.stage是MERGE_SORT，说明分片已排序；若看到SORT+SHARDING_FILTER，说明排序压到了 Mongos 端
必须确保分片能本地排序：索引要带分片键前缀
分片集群中，只有满足「查询条件包含分片键等值匹配」+「排序字段在索引中紧随其后」，分片才能利用索引完成本地排序。否则 Mongos 只能走 scatter-gather 模式。
- 错误示例：
shard key = {region: 1, userId: 1}，却对{createdAt: -1}单独建索引并排序 → 分片无法定位局部有序范围，必然全扫 - 正确做法：建复合索引时，把分片键字段放在最左，排序字段紧跟其后，例如：
db.orders.createIndex({region: 1, userId: 1, createdAt: -1}) - 若查询只含
{region: "US"}（等值），再.sort({createdAt: -1})，就能触发每个分片独立排序，Mongos 只 merge 有序流 - 注意：
allowDiskUse: true对 Mongos 端排序无效，它只作用于单个分片内的聚合阶段
深分页场景下，Merge Sort 会失效
当使用 skip(10000).limit(20) 时，即使每个分片都排好了序，Mongos 也必须从每个分片取至少 10020 条才能 merge 出全局第 10001–10020 条 —— 数据传输和内存压力陡增。
- 典型现象：
executionStats.nReturned远大于limit值，totalDocsExamined在各分片上累加爆炸 - 解法不是调大内存，而是改用「游标分页」：
.sort({createdAt: -1}).find({createdAt: {$lt: lastCreatedAt}}).limit(20) - 该方式要求排序字段高基数、无重复（或配合
_id消除歧义），且不能跳页 —— 这是分片环境下唯一可扩展的方案 - 如果业务强依赖跳页，说明分片键或查询模型可能选错了，需重新评估是否真需要分片，或考虑冷热分离+预聚合
最容易被忽略的一点：分片键本身是否参与排序逻辑。如果排序字段和分片键完全无关（比如按时间排序，但分片键是用户 ID），那无论怎么建索引，Mongos 都得收全量再 merge —— 这时候与其硬扛，不如重构分片策略，或把排序逻辑前置到应用层缓存。
