$sortByCount不能替代group+sort，因其仅支持单字段表达式、强制count降序、无条件过滤能力，且输出结构固定为_id和count，不支持复合分组、去重统计或自定义排序逻辑。
为什么 $sortByCount 不能直接替代 group + sort？
因为 $sortByCount 本质是 $group 和 $sort 的语法糖，它强制按计数降序排，且只接受单个字段表达式（如 "$status"），不支持复合条件、去重统计或自定义排序逻辑。你如果写 {"$sortByCount": {"$ifNull": ["$category", "unknown"]}}，MongoDB 会直接报错：Expression must be a field path string。
正确用法：只传字段路径字符串，别加表达式
它只认形如 "$field" 的字符串，内部自动展开为 {$group: {_id: "$field", count: {$sum: 1}}} 再 {$sort: {count: -1}}。常见误用和对应解法：
- 想统计非空分类？先用
$replaceRoot或前置$set处理字段，再对新字段用$sortByCount - 想按多个字段分组？必须放弃
$sortByCount，改用显式$group+$sort - 想排除 null/missing 值？在
$sortByCount前加$match过滤，例如{"$match": {"category": {"$exists": true, "$ne": null}}}
示例（合法）：
[
{"$match": {"category": {"$exists": true}}},
{"$sortByCount": "$category"}
]
性能差异：$sortByCount 和手动 group + sort 一样快吗？
底层执行计划完全一致，$sortByCount 就是语法糖，没有额外开销。但要注意：它无法利用复合索引优化分组字段——MongoDB 只能使用 category 单字段索引加速 $group 阶段。如果你的集合有上亿文档，且 category 基数极高（比如 UUID），内存消耗和排序压力不会因用了 $sortByCount 而降低。
- 确保
category字段上有单字段索引：db.collection.createIndex({"category": 1}) - 如果聚合结果要跳过前 N 条（比如分页查 Top 100），记得加
$limit在$sortByCount后，避免全量排序
遇到 “Exceeded memory limit” 错误怎么办？
$sortByCount 触发的是 $group 阶段内存限制，默认 100MB。错误信息是：Sort exceeded memory limit of 104857600 bytes。这不是排序本身的问题，而是分组键太多导致中间结果膨胀。
- 优先加
$match缩小输入文档量（比如限定时间范围、状态） - 检查
category是否存在大量唯一值（如用户 ID、毫秒级时间戳），这种场景不该用$sortByCount - 不得已时启用磁盘排序：
{"allowDiskUse": true}，但会明显变慢
真正该警惕的，是把 $sortByCount 当万能计数工具——它只适合“字段值离散度适中、业务语义明确”的分类统计，比如订单状态、商品类型、HTTP 状态码。
