聚合函数深度拆解：从SQL执行顺序到CLR排序坑与MongoDB实现-代码聚汇网

聚合函数深度拆解：从SQL执行顺序到CLR排序坑与MongoDB实现

斯迈尔齿科·2026-08-30·阅读 21 GEO检测（免费）

SQL聚合函数查询执行顺序GROUP BY

|难度：普通|阅读约 52 分钟

前阵子帮朋友排查一个线上慢查询，翻到一段让我印象深刻的SQL：SELECT后面写了聚合函数，WHERE里面又想对聚合结果筛一遍，直接被数据库怼了个"无效使用聚合函数"。这类问题我在不同团队见过太多次，说到底是大家对表格查询语句的理解停在"能跑就行"，没真正吃透数据库执行查询的先后顺序。

这次我把表格查询语句里最核心、也最容易被低估的部分——聚合函数——从头到尾拆一遍。内容包括：查询执行顺序、COUNT/SUM/AVG/MIN/MAX的边界行为、GROUP BY和HAVING的配合方式，再重点讲一个我实际踩过的硬核问题：MSSQL CLR聚合函数排序顺序不生效的完整排查过程。文章最后会把SQL聚合思维搬到MongoDB聚合管道，看看聚合函数在另一个世界里怎么等价实现。

适读人群：写SQL两年以上但没系统梳理过聚合逻辑的开发，正在被CLR聚合排序折磨的DBA或.NET工程师，以及刚接触MongoDB聚合管道、想用SQL经验加速上手的同学。全文不吹概念，只讲能落到代码里的东西。

1. 执行顺序决定一切：为什么WHERE里不能写聚合函数

很多人学SQL是从"照着例子抄"开始的，SELECT、FROM、WHERE、GROUP BY这些关键字背得滚瓜烂熟，但数据库到底按什么顺序处理这些子句，反而没人深究。这个顺序一旦搞明白，很多报错根本不用查，一眼就知道问题出在哪。

1.1 数据库的逻辑执行顺序

先记住这个顺序，这是所有关系型数据库（SQL Server、MySQL、PostgreSQL、Oracle）通用的逻辑规则：

FROM：确定要读取的表，执行JOIN
WHERE：对FROM阶段产生的行做逐行过滤
GROUP BY：按指定列分组
HAVING：对分组后的结果做过滤
SELECT：计算投影列、别名、聚合表达式
ORDER BY：对最终结果排序
LIMIT/OFFSET或TOP/FETCH：截取行

注意，我说的是"逻辑执行顺序"，不是"物理执行顺序"。数据库优化器实际干活的时候会各种调整，但逻辑上它必须保证最终结果等价于这个顺序。这个顺序解释了一堆日常困惑。

为什么WHERE里不能直接用列别名？因为SELECT阶段排在WHERE后面，别名此时还没生成。

为什么WHERE里不能写聚合函数？因为聚合是GROUP BY阶段才开始计算的，WHERE阶段面对的还是原始行，聚合值根本不存在。报错"无效使用聚合函数"说的就是这个。

为什么ORDER BY里能用别名甚至能写SELECT里的聚合表达式？因为排序是在SELECT算完之后才进行的。

1.2 一个完整示例串起整个流程

拿员工表举例，表结构很简单：

sql复制CREATE TABLE employee (
    emp_id INT PRIMARY KEY,
    name NVARCHAR(50),
    dept_id INT,
    salary DECIMAL(10,2),
    status NVARCHAR(20),
    hire_date DATE
);

最常见的分组统计查询：

sql复制SELECT 
    dept_id,
    COUNT(*) AS emp_cnt,
    ROUND(AVG(salary), 2) AS avg_salary,
    MAX(salary) AS max_salary
FROM employee
WHERE status = 'active'
GROUP BY dept_id
HAVING COUNT(*) >= 5
ORDER BY avg_salary DESC;

这条SQL的实际处理过程：

先FROM employee拿到全表，然后WHERE status = 'active'把所有非在职员工的行过滤掉；接着按dept_id分组，每个部门形成一组；HAVING判断每组行数是否大于等于5，把人数不足的小组扔掉；SELECT阶段对保留下来的组计算COUNT(*)、AVG(salary)、MAX(salary)，生成最终列；最后按平均工资倒序输出。

我见过不少人在WHERE里写COUNT(*) > 10想过滤掉记录数少的部门，然后被数据库报错。理解了执行顺序你就知道，这个条件只能在HAVING里写，因为WHERE阶段"组"这个东西还不存在。

1.3 理解执行顺序对排错的实际意义

执行顺序不只是应付面试，它在真实排错场景里特别有用。我举两个比较典型的：

第一，ORDER BY使用SELECT别名与子句顺序的坑。在SQL Server里，ORDER BY可以用别名，但如果你试图在ORDER BY里引用一个既不在SELECT中、也不在分组键中的原始列，就会报错。这是因为逻辑上此时只有SELECT输出的列和分组键是可用的。

第二，HAVING能不能用别名，不同数据库行为不一样。MySQL里HAVING avg_salary > 8000能通过，因为它对SELECT别名的解析更宽松；SQL Server则会直接报"列名无效"。别把一种数据库的写法想当然套到另一种上。碰到这类问题，回到执行顺序去推演，比死记各种数据库的兼容性差异靠谱得多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 聚合函数逐个抠细节：COUNT、SUM、AVG、MIN/MAX的边界行为

聚合函数看着简单，不就是COUNT数个数、SUM求和嘛。但真到了线上，因为NULL值处理、数据类型、去重逻辑翻车的案例我见得太多了。这节把每个常用聚合函数的边界行为都过一遍。

2.1 COUNT一族：COUNT(*)、COUNT(1)、COUNT(列)到底差在哪

先给结论：在主流数据库里，COUNT(*)和COUNT(1)性能没有本质差异，写法上纯粹是习惯问题。真正有区别的是COUNT(列名)。

COUNT(*)统计的是结果集中的行数，不管某列是不是NULL，都算一行。
COUNT(1)等价于COUNT(*)，因为1是一个常量表达式，每一行都非NULL，所以数的也是行数。
COUNT(具体列)只统计该列非NULL的行数。这一点极其关键，也是很多人写错的地方。

sql复制-- 假设employee表有100行，其中20行salary为NULL
SELECT 
    COUNT(*) AS all_rows,        -- 返回100
    COUNT(salary) AS salary_cnt  -- 返回80
FROM employee;

COUNT(DISTINCT 列)则是统计非NULL去重后的数量，这个是最耗资源的聚合操作之一，尤其在大表上，内存和CPU消耗都很夸张。需要准确去重就老实写，但别随手给大字段加DISTINCT。

2.2 SUM和AVG对NULL值的处理：默认忽略但结果可能为NULL

SUM和AVG在计算时默认忽略NULL值，这个行为跟COUNT(列)是一致的。但有个反直觉的坑：如果参与计算的所有行全是NULL，SUM返回的不是0，而是NULL。

sql复制-- 假设某部门所有员工的绩效奖金bonus列都为NULL
SELECT 
    dept_id,
    SUM(bonus) AS total_bonus,   -- 返回NULL
    AVG(bonus) AS avg_bonus      -- 返回NULL
FROM employee
GROUP BY dept_id;

很多报表系统拿到NULL直接显示空白，业务方看到"这个部门奖金总额是空"就会质疑。正确的兜底写法是用ISNULL或COALESCE包一层：

sql复制SELECT 
    dept_id,
    COALESCE(SUM(bonus), 0) AS total_bonus,
    COALESCE(AVG(bonus), 0) AS avg_bonus
FROM employee
GROUP BY dept_id;

AVG还有一个容易踩的坑：AVG(整数列)在某些数据库里会做整数除法。SQL Server算AVG(salary)会返回带小数的结果，因为DECIMAL类型本身带精度；但如果你对一个INT列求平均，比如算术平均算出来是3.5，SQL Server会返回3.5（它内部会转成更宽的类型），而MySQL在某种模式下也类似。最稳妥的办法是显式转换：

sql复制-- 避免整数除法的隐患
SELECT AVG(CAST(score AS DECIMAL(10, 2))) FROM exam_score;

2.3 MIN/MAX的隐藏价值：不只是取最小最大

MIN和MAX除了数值，还能作用于日期和字符串。取最大日期是这个函数最常用的隐藏场景之一：

sql复制-- 查询每个部门最近一次入职日期
SELECT dept_id, MAX(hire_date) AS latest_hire
FROM employee
GROUP BY dept_id;

MIN和MAX同样忽略NULL，这跟SUM一致。但要注意，如果对字符串列求MAX，比较的是字符串排序规则（collation），不同数据库、不同排序规则的字符集设置，结果可能不一样。比如大小写敏感的排序规则下，'b'和'B'谁大取决于具体规则。这种场景下别对结果有想当然的预期，先确认排序规则。

另外还有个不算陷阱、但值得提醒的点：MIN/MAX无法直接告诉你"这个最大值是谁的那一行"。想拿到对应的整行记录，得用窗口函数或者子查询关联，单纯靠聚合函数做不到。

sql复制-- 错误示范：想拿薪资最高的员工姓名，这样写字段不在GROUP BY里，会报错
SELECT dept_id, name, MAX(salary)
FROM employee
GROUP BY dept_id;

-- 正确写法之一：窗口函数
SELECT dept_id, name, salary
FROM (
    SELECT dept_id, name, salary,
           ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn
    FROM employee
    WHERE status = 'active'
) t
WHERE rn = 1;

窗口函数虽然也带聚合的影子，但它不属于本次讨论的传统聚合函数范畴，这里先点到为止。实际开发中，ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)是"取每组TopN"这个需求的标准解法，比反复用子查询关联优雅得多。

3. GROUP BY与HAVING配合：分组聚合常见的翻车现场

GROUP BY本身不复杂，但跟SELECT列、WHERE、HAVING揉在一起，就容易出现各种反直觉的行为。这一节把几个高频翻车点集中说清楚。

3.1 非聚合列随便SELECT导致的ONLY_FULL_GROUP_BY报错

最常见的报错：SELECT里写了既不在GROUP BY中、也不是聚合函数的列。MySQL在开启ONLY_FULL_GROUP_BY模式后对这种写法直接拒绝，SQL Server、PostgreSQL等数据库默认也都不允许。

为什么数据库要这么严格？因为分组之后，组内每一列可能有多个值，数据库不知道你想选哪一个。比如按dept_id分组后，name列在组内可能有好几个员工姓名，直接SELECT name到底取哪个？没有语义。这时候要么把name加进GROUP BY（那分组粒度就变了），要么用MAX(name)、MIN(name)这类聚合函数从组内挑一个，要么用ANY_VALUE(name)（MySQL提供）明确告诉数据库"随便取一个"。

sql复制-- 合法但语义要清楚：按dept_id + name联合分组
SELECT dept_id, name, COUNT(*)
FROM employee
GROUP BY dept_id, name;

-- 合法且明确：每组随便取一个name
-- 仅MySQL支持
SELECT dept_id, ANY_VALUE(name) AS sample_name, COUNT(*)
FROM employee
GROUP BY dept_id;

这个报错不是数据库刁难你，恰恰是数据库在救你。它逼你想清楚分组粒度到底是什么。我见过有同事为了消掉报错，把查询里所有列一股脑塞进GROUP BY，结果本来想统计"部门人数"，变成了"部门+姓名的人数"，数据全错。分组粒度是聚合查询的灵魂，动手之前先用一句话描述清楚"我要按什么维度统计什么指标"。

3.2 WHERE与HAVING的分工：一步错，性能和结果都错

WHERE在分组前过滤行，HAVING在分组后过滤组，这个区别前面提过，但实际场景里经常有人用错。

一个典型场景：统计每个部门中月薪超过8000的员工数量，并且只要员工数大于等于3的部门。

sql复制SELECT dept_id, COUNT(*) AS high_salary_cnt
FROM employee
WHERE salary > 8000
GROUP BY dept_id
HAVING COUNT(*) >= 3;

WHERE salary > 8000先把低薪员工滤掉，剩下的才参与分组计数。如果把salary > 8000误写到HAVING里：

sql复制-- 错误但有迷惑性的写法
SELECT dept_id, COUNT(*) AS high_salary_cnt
FROM employee
GROUP BY dept_id
HAVING salary > 8000;

这写法在多数数据库里直接报错，因为HAVING中引用的salary不在分组键里，也不是聚合函数。就算某些数据库解析宽松，它也无法表达"按薪资过滤后再计数"的语义。

从性能角度说，能用WHERE过滤的千万别放到HAVING。WHERE在分组前缩减数据量，参与分组的数据越少，聚合越快；放到HAVING不仅没起到缩减作用，还可能因为HAVING中涉及非分组列导致优化器无法走索引。这条规则可以说是聚合查询性能的第一性原则。

3.3 多维度汇总：GROUPING SETS、ROLLUP、CUBE

如果只是单维度分组，GROUP BY绰绰有余。但遇到"既要按部门统计，又要按部门+城市统计，还要看总计"这种多级汇总需求时，写多条SQL再UNION太笨重，这时候就该上GROUPING SETS了。

sql复制SELECT 
    dept_id,
    city,
    COUNT(*) AS emp_cnt
FROM employee
GROUP BY GROUPING SETS (
    (dept_id, city),
    (dept_id),
    ()
);

()代表全表总计。这三个分组分别输出部门+城市粒度、部门粒度、总计三份结果，用GROUPING函数可以判断某行属于哪个粒度。ROLLUP是GROUPING SETS的简化版，按层级做汇总，常见于报表的"小计/总计"场景。

sql复制-- 按部门、部门+城市、总计三级汇总
SELECT dept_id, city, COUNT(*) AS emp_cnt
FROM employee
GROUP BY ROLLUP (dept_id, city);

这些高级分组语法各数据库都支持，但写法略有差异。日常业务里如果只做一次性报表，写多条SQL也行；如果这个查询会被频繁执行，GROUPING SETS一次扫描完成多级聚合，性能优势非常明显。

4. 一个硬核坑：MSSQL CLR聚合函数排序顺序不生效的完整排查

说到MSSQL CLR聚合函数排序顺序不生效，这个坑我印象极深，因为当年排查了将近一天才找到根因。先说结论：CLR自定义聚合函数接收输入行的顺序，在SQL Server里是不保证的，你写不写ORDER BY都没用。 这个结论反直觉，但我用实际案例带你把整个链路走一遍。

4.1 什么场景下你会去写一个CLR聚合函数

SQL Server内置的聚合函数就那么几个：SUM、AVG、COUNT、MIN、MAX。遇到"把一组字符串按某种顺序拼接起来""计算中位数""算加权平均"这类需求，内置函数就无能为力了。

以字符串拼接为例，SQL Server 2017之前没有STRING_AGG，那时候最常见的方案是FOR XML PATH硬拼。但FOR XML PATH写起来繁琐，于是一部分团队选择用.NET写一个自定义聚合函数，编译成DLL，注册到SQL Server里，然后像内置函数一样用。这就是CLR聚合函数。

CLR聚合函数的核心是一个类，必须实现四个方法：Init()初始化、Accumulate()逐行接收输入、Merge()合并并行计算的分区结果、Terminate()输出最终结果。C#代码大概长这样：

csharp复制using System;
using System.Collections.Generic;
using System.Data.SqlTypes;
using System.Linq;
using Microsoft.SqlServer.Server;

[Serializable]
[SqlUserDefinedAggregate(Format.UserDefined, MaxByteSize = -1)]
public class OrderedConcat : IBinarySerialize
{
    private List<KeyValuePair<int, string>> _items;

    public void Init()
    {
        _items = new List<KeyValuePair<int, string>>();
    }

    public void Accumulate(SqlInt32 seq, SqlString value)
    {
        if (seq.IsNull || value.IsNull) return;
        _items.Add(new KeyValuePair<int, string>(seq.Value, value.Value));
    }

    public void Merge(OrderedConcat other)
    {
        if (other != null && other._items != null)
            _items.AddRange(other._items);
    }

    public SqlString Terminate()
    {
        if (_items == null || _items.Count == 0)
            return SqlString.Null;

        var ordered = _items.OrderBy(kv => kv.Key);
        return new SqlString(string.Join(",", ordered.Select(kv => kv.Value)));
    }

    public void Read(System.IO.BinaryReader r) { }
    public void Write(System.IO.BinaryWriter w) { }
}

注册到SQL Server：

sql复制CREATE ASSEMBLY OrderedConcat FROM 'C:\path\OrderedConcat.dll';
GO
CREATE AGGREGATE dbo.OrderedConcat(@seq INT, @value NVARCHAR(MAX))
RETURNS NVARCHAR(MAX)
EXTERNAL NAME OrderedConcat.OrderedConcat;

看起来没毛病，Accumulate按行接收，Terminate输出。但问题是：Accumulate接收行的顺序，真的跟你期望的一样吗？

4.2 现象复现：ORDER BY完全不影响聚合输入顺序

我当时的需求是把某张流水表按流水号拼接单据编号。表结构大致是：

sql复制CREATE TABLE dbo.TestValues (
    GrpId INT,
    SeqNo INT,
    Val NVARCHAR(20)
);

INSERT INTO dbo.TestValues VALUES (1, 1, 'A'), (1, 3, 'C'), (1, 2, 'B'), (2, 2, 'Y'), (2, 1, 'X');

期望输出：第一组按SeqNo排序拼接为A,B,C。

初始写法：

sql复制SELECT 
    GrpId, 
    dbo.OrderedConcat(SeqNo, Val) AS result
FROM dbo.TestValues
GROUP BY GrpId;

跑出来完全随机，甚至第一组输出的是A,C,B或B,A,C。然后我尝试加ORDER BY：

sql复制SELECT 
    GrpId, 
    dbo.OrderedConcat(SeqNo, Val) AS result
FROM dbo.TestValues
GROUP BY GrpId
ORDER BY GrpId;

结果还是不对。我又试了在子查询里先排序再聚合：

sql复制SELECT GrpId, dbo.OrderedConcat(SeqNo, Val) AS result
FROM (
    SELECT * FROM dbo.TestValues ORDER BY SeqNo
) t
GROUP BY GrpId;

依然不对。这时候我意识到问题比想象的深。

4.3 根因定位：执行计划里的Stream Aggregate与Hash Aggregate

打开实际执行计划，发现GROUP BY对应的运算符是Hash Aggregate，而不是Stream Aggregate。

这两个聚合运算符的行为完全不同：

Stream Aggregate：要求输入流已经按分组键排好序，然后顺序扫描，遇到分组键变化就输出一组结果。它天然维护了组内行的输入顺序。
Hash Aggregate：把输入行按分组键哈希到内存中的桶里，每个桶里的行是无序追加的。等所有行处理完，再逐个桶输出聚合结果。哈希桶本身就是无序的。

CLR聚合函数在GROUP BY场景下，优化器绝大多数时候会选择Hash Aggregate，因为Hash Aggregate不需要预先排序，代价更低。代价低的代价是：你的聚合函数收到什么顺序的行，完全取决于数据在哈希桶里的摆放顺序，而这个顺序对于调用方是黑盒。

你以为SQL Server会把ORDER BY的语义传递到聚合输入里，其实不会。ORDER BY作用于查询最终结果的输出排序，发生在所有聚合计算完成之后。聚合函数内部拿到的行顺序，跟最终ORDER BY没有半毛钱关系。

另一个加剧问题的是并行执行。一旦查询被并行化，数据会被拆到多个线程分别处理，每个线程各自调用Accumulate累积一部分行，最后通过Merge合并。并行线程之间处理哪个分块、什么顺序处理，完全不可控，行顺序在合并时早就乱套了。

4.4 修复方案：在Terminate里排一次序，或者干脆别用CLR

知道了根因，修复方案就清晰了。既然Accumulate收到的顺序不可控，那就不要依赖它的顺序，而是把需要排序的键值收集起来，在Terminate阶段统一排序。这就是我前面代码里_items.OrderBy(kv => kv.Key)这行的意义。

这个方案的思路是：Accumulate阶段不管行顺序，把所有(SeqNo, Val)都塞进集合；Terminate阶段对整个集合按SeqNo排序后再拼接。这样无论执行计划怎么折腾，最终输出都正确。

还有个细节要注意：Format.UserDefined配合MaxByteSize = -1时，SQL Server会要求你的类实现IBinarySerialize接口，也就是Read和Write方法，用来跨并行分区序列化聚合中间状态。我见过有人图省事留空实现，结果并行执行下Merge时数据丢失或乱序。Read/Write里必须把_items完整序列化，这个不能偷懒。

但如果你问我个人建议，更推荐的方案是：能不用CLR就不用CLR。SQL Server 2017及以上版本已经有内置的STRING_AGG，完美支持组内排序：

sql复制SELECT 
    GrpId, 
    STRING_AGG(Val, ',') WITHIN GROUP (ORDER BY SeqNo) AS result
FROM dbo.TestValues
GROUP BY GrpId;

WITHIN GROUP (ORDER BY ...)就是专门为聚合函数的输入排序设计的语法，是官方支持的、保证生效的排序，比CLR聚合的"自救"方案清爽得多。如果因为某些原因必须用老版本，FOR XML PATH也是比CLR更稳妥的替代方案：

sql复制SELECT 
    GrpId,
    STUFF((
        SELECT ',' + Val
        FROM dbo.TestValues t2
        WHERE t2.GrpId = t1.GrpId
        ORDER BY t2.SeqNo
        FOR XML PATH('')
    ), 1, 1, '') AS result
FROM dbo.TestValues t1
GROUP BY GrpId;

FOR XML PATH虽然历史上被大量用作字符串聚合的hack，且其顺序在严格意义上同样不是百分百规范保证的，但它在标量子查询中配合ORDER BY的排序表现，在SQL Server社区中被广泛验证是稳定的。相比CLR的完全黑盒，这个方案的可控性高出不少。

4.5 别把临时手段当药方：MAXDOP 1和索引都不保险

排查过程中，我还试过一些"偏方"，这里一起说清楚，免得你走弯路。

第一个偏方是加OPTION (MAXDOP 1)强制单线程。把并行关掉确实能让执行计划更简单，有时候Accumulate收到的顺序恰好对了。但这不是正式保障——就算单线程，Hash Aggregate的哈希桶遍历顺序依然不是你可以假设的，这次碰巧对，下次数据分布变了、内存压力变了，结果可能又不一样。把正确性寄托在"碰巧"上，迟早出事。

第二个偏方是给GROUP BY列建索引，试图诱导优化器用Stream Aggregate。Stream Aggregate确实会保持输入顺序，理论上如果数据正好按GrpId排序，组内行再按某个顺序排列，Accumulate就能按序接收。但问题在于：优化器依然可能因为成本估算而选择Hash Aggregate，即使你建了索引。你无法强制优化器"必须用Stream Aggregate喂数据给CLR函数"。

所以最终结论只有两条路：要么在CLR内部做排序，要么换内置方案。 我后来的项目里遇到类似需求，统一规定：新代码一律用STRING_AGG，老代码里的CLR聚合逐步迁移替换。CLR聚合函数不是不能写，但要清楚它的能力边界——它从来就不承诺输入顺序。

5. 换一个世界：MongoDB聚合函数的等价实现与SQL思维迁移

聊完SQL Server的聚合，再说说MongoDB。现在很多团队是SQL和NoSQL混用，业务里既有MySQL又有MongoDB。搜索热词里"MongoDB聚合函数"关注度不低，说明不少人带着SQL经验去写MongoDB聚合时，确实遇到了思维转换的障碍。

5.1 MongoDB没有SELECT，但有一个更灵活的东西

MongoDB的聚合框架是一套管道（pipeline），数据像流水线上的零件一样，经过一个又一个阶段（stage）加工，最终输出结果。每个stage只做一件事，所有stage串起来就是完整的聚合逻辑。

对应到SQL：

$match：等价于WHERE，过滤文档
$project：等价于SELECT列，可以做字段投影、重命名、表达式计算
$group：等价于GROUP BY，是聚合的核心
$sort：等价于ORDER BY
$limit：等价于LIMIT
$unwind：把数组字段拆成多行，SQL没有直接对应物
$lookup：等价于LEFT JOIN

一个典型的带聚合的查询长这样：

javascript复制db.orders.aggregate([
    { $match: { status: "completed" } },
    {
        $group: {
            _id: "$customerId",
            totalAmount: { $sum: "$amount" },
            orderCount: { $sum: 1 },
            avgAmount: { $avg: "$amount" }
        }
    },
    { $sort: { totalAmount: -1 } },
    { $limit: 10 }
])

这个管道的意思：先筛出已完成的订单，按customerId分组，计算每个客户的订单总金额、订单数、平均金额，按总金额倒序取前10个。跟SQL的执行顺序几乎一一对应：先过滤、再分组、再排序、再截取。

5.2 $group输出顺序不保证：必须先$sort再排序

SQL里GROUP BY之后不写ORDER BY，结果顺序也是不保证的，但很多数据库碰巧会按分组键返回排好序的结果，导致大家产生了错觉。MongoDB的$group更直白：它明确不保证输出顺序。

想要排序，必须在$group后面显式加$sort。顺序就是管道中stage的前后顺序，这点比SQL更直观。

javascript复制// 这样写，输出顺序是没有保证的
db.orders.aggregate([
    { $group: { _id: "$status", total: { $sum: "$amount" } } }
]);

// 想要按total倒序，必须加$sort
db.orders.aggregate([
    { $group: { _id: "$status", total: { $sum: "$amount" } } },
    { $sort: { total: -1 } }
]);

这跟上一节CLR聚合的教训本质上是同一个问题：聚合结果的顺序，永远不要依赖隐含行为，要显式声明。 只不过MongoDB把这个设计原则贯彻得更彻底。

5.3 SQL聚合函数与MongoDB聚合表达式的对照表

我整理了常用SQL聚合操作在MongoDB里的等价写法，方便你随时翻：

SQL写法	MongoDB聚合管道写法
`WHERE col = 'x'`	`{ $match: { col: 'x' } }`
`GROUP BY dept_id`	`{ $group: { _id: "$dept_id" } }`
`GROUP BY a, b`	`{ $group: { _id: { a: "$a", b: "$b" } } }`
`COUNT(*)`	`{ $sum: 1 }`
`COUNT(col)`	`{ $sum: { $cond: [ { $ne: ["$col", null] }, 1, 0 ] } }`
`SUM(col)`	`{ $sum: "$col" }`
`AVG(col)`	`{ $avg: "$col" }`
`MIN(col)`	`{ $min: "$col" }`
`MAX(col)`	`{ $max: "$col" }`
`HAVING COUNT(*) > 10`	`$group`后接`{ $match: { count: { $gt: 10 } } }`
`ORDER BY col DESC`	`{ $sort: { col: -1 } }`
`LIMIT 10`	`{ $limit: 10 }`

注意HAVING在管道里的位置：$match放在$group后面，就等价于SQL的HAVING；放在$group前面，就等价于WHERE。同一个$match操作符，位置不同语义完全不同，这是MongoDB聚合比SQL更直白也更容易弄混的地方。

5.4 $group之前先思考：$project、$unwind和$lookup的顺序

MongoDB聚合性能好坏，很大程度上取决于stage顺序。三个实用原则：

第一，$match尽量往前放。跟SQL的WHERE前置一样，早过滤早省事。$match如果能利用索引，效果更好，但要注意：$match放在$group之后时，它处理的是分组后的结果，通常无法利用原集合的索引。

第二，$sort如果是为了配合$group取每组"第一条/最后一条"，可以放在$group之前。$group里有$first和$last操作符，它们返回的是输入流中该组第一个/最后一个文档的字段值，所以输入顺序至关重要。想要正确的"每组最新一条"，先$sort再$group，配合$first取。

javascript复制// 每个客户最近一笔订单的金额
db.orders.aggregate([
    { $sort: { customerId: 1, createdAt: -1 } },
    {
        $group: {
            _id: "$customerId",
            latestAmount: { $first: "$amount" }
        }
    }
]);

第三，$unwind要三思而后行。$unwind把数组字段拆成多行，数据量会成倍膨胀，是聚合管道中最容易引发性能问题的操作。如果只是统计数组长度，用$size表达式就够了，没必要$unwind。

6. 聚合查询提速的几个实操习惯：索引、过滤与写法

最后一节，把聚合查询的调优经验汇总一下。这些习惯不区分SQL和MongoDB，本质思路相通。

6.1 WHERE前置比任何优化技巧都重要

聚合查询的成本主要由参与聚合的数据量决定。能在WHERE阶段干掉的数据，绝不留到GROUP BY阶段处理。

举个例子，统计2024年每个部门的入职人数。下面两种写法结果一样，性能差很多：

sql复制-- 写法一：先算所有年度的分组，再过滤
SELECT dept_id, COUNT(*) AS cnt
FROM (
    SELECT dept_id, YEAR(hire_date) AS hire_year
    FROM employee
) t
WHERE hire_year = 2024
GROUP BY dept_id;

-- 写法二：先过滤再分组，数据量直接减掉一大截
SELECT dept_id, COUNT(*) AS cnt
FROM employee
WHERE hire_date >= '2024-01-01' AND hire_date < '2025-01-01'
GROUP BY dept_id;

写法二还额外利用了hire_date上的索引范围扫描。写法一对hire_date套了YEAR()函数，就算有索引也用不上，这叫"函数导致索引失效"。记住一个原则：过滤条件里的列，尽量保持裸列，别套函数。

6.2 覆盖索引与GROUP BY列的配合

GROUP BY列如果能有索引支撑，数据库可以走Stream Aggregate（有序），省掉排序和哈希的开销。更进一步，如果索引能覆盖查询需要的所有列，连回表都省了。

sql复制-- 高频分组查询：按dept_id统计在职员工薪资
SELECT dept_id, AVG(salary)
FROM employee
WHERE status = 'active'
GROUP BY dept_id;

-- 合适的索引
CREATE INDEX idx_emp_status_dept_salary 
ON employee(status, dept_id, salary);

这个索引的设计思路：status用于WHERE等值过滤，dept_id用于分组，salary用于聚合计算。查询需要的三列全部在索引里，数据库直接扫索引就能完成全部工作。MongoDB同理，$match字段、$group字段、$sort字段尽量放进同一个复合索引，顺序按"等值条件优先、范围次之、排序分组最后"来排。

6.3 别在聚合表达式里做无谓计算

聚合函数内部的表达式越简单越好。SUM(price * quantity)这种写法本身没问题，但如果可以在写入时冗余一个amount字段，或者至少在WHERE阶段尽量缩小范围，性能差别会很明显。

还有一个我常提醒的：COUNT(1)和COUNT(*)用哪个不重要，重要的是别写成COUNT(具体列)导致语义错误。如果你发现某段SQL里COUNT(*)和COUNT(col)结果一致，那是因为碰巧该列没有NULL；一旦出现NULL，结果就悄悄变了。代码review时看到这种写法，务必确认写的人知道区别。

6.4 MongoDB聚合的另类性能提醒

MongoDB聚合管道有个内存限制：$group和$sort默认最多使用100MB内存，超出后会报错。处理超大分组时，需要显式开启allowDiskUse: true让MongoDB把中间结果溢写到磁盘：

javascript复制db.orders.aggregate(
    [
        { $group: { _id: "$customerId", total: { $sum: "$amount" } } },
        { $sort: { total: -1 } }
    ],
    { allowDiskUse: true }
);

但allowDiskUse不是银弹，磁盘溢写比内存慢得多。真正该做的是在业务上限制一次聚合处理的数据范围，比如按时间分段聚合成中间结果表，再对中间结果二次聚合。这也是典型的"预聚合"思路：报表系统不可能每次实时扫全量数据，宁可定时把昨天的聚合结果算好存起来，查询时只算增量。

预聚合这个思想在SQL里同样适用，比如用物化视图或者定时任务生成汇总表。聚合函数解决的是"实时算出来"的问题，但当数据量大到一定程度，实时算不如"提前算好"。

我自己的体会是，聚合查询的调优永远绕不开三个核心：先缩小数据范围，再减少参与计算的行数和列数，最后才是考虑要不要换一种写法或者用高级特性。顺序别搞反，不然很容易出现"索引建了一堆，查询还是慢"的尴尬局面。