在数据库查询场景中，聚合函数和排序操作的执行顺序直接影响最终的查询结果，这是SQL编写过程中需要明确的核心逻辑之一。标准SQL的查询执行有固定的逻辑顺序，理解这个顺序就能清晰判断聚合函数和排序的先后关系。
标准SQL查询的执行顺序
首先需要明确标准SQL查询的完整执行步骤，整体顺序如下：
- FROM：确定查询的数据来源表
- WHERE：对原始数据进行行级过滤
- GROUP BY：对过滤后的数据进行分组
- 聚合函数计算：对每个分组执行SUM、COUNT、AVG等聚合操作
- HAVING：对分组后的结果进行过滤
- SELECT：选择需要返回的列
- DISTINCT：对结果去重
- ORDER BY：对最终结果进行排序
- LIMIT：限制返回的行数
从这个顺序可以看出，聚合函数的执行是在ORDER BY之前的，也就是说排序操作是针对聚合函数计算完成后的结果进行的。
聚合函数和排序的执行逻辑验证
我们可以通过一个具体的示例来验证这个执行顺序，假设有一张order_table表，存储了用户的订单信息，表结构如下：
| 列名 | 类型 | 说明 |
|---|---|---|
| user_id | int | 用户ID |
| order_amount | decimal | 订单金额 |
现在需要查询每个用户的订单总金额，并且按照总金额从高到低排序，对应的SQL语句如下：
-- 查询每个用户的订单总金额，按总金额降序排序
SELECT
user_id,
SUM(order_amount) AS total_amount
FROM order_table
GROUP BY user_id
ORDER BY total_amount DESC;
这段语句的执行过程是先通过GROUP BY user_id对数据分组，然后对每个组执行SUM(order_amount)聚合计算，得到每个用户的总金额，最后再对包含total_amount的结果集执行ORDER BY排序，完全符合之前提到的执行顺序。
特殊情况说明
需要注意一种容易混淆的场景：如果排序的字段是原始表中的列，而不是聚合函数计算后的结果，会不会影响执行顺序？答案是否定的，ORDER BY始终是在聚合之后执行的。比如下面的语句：
-- 查询每个用户的订单总金额，按用户ID升序排序
SELECT
user_id,
SUM(order_amount) AS total_amount
FROM order_table
GROUP BY user_id
ORDER BY user_id ASC;
这里虽然排序用的是user_id，但user_id是分组列，在聚合完成后结果集中已经存在，排序依然是在聚合操作完成之后进行的，不会提前执行排序再计算聚合。
常见错误示例
很多开发者会误以为可以在WHERE子句中使用聚合函数的结果进行排序，这是错误的，因为WHERE执行在聚合之前，此时还没有聚合结果。比如下面的错误写法：
-- 错误示例：WHERE子句中使用聚合函数
SELECT
user_id,
SUM(order_amount) AS total_amount
FROM order_table
WHERE SUM(order_amount) > 100 -- 这里会报错，WHERE不支持聚合函数
GROUP BY user_id
ORDER BY total_amount DESC;
如果需要对聚合后的结果进行过滤，应该使用HAVING子句，HAVING是执行在聚合之后、ORDER BY之前的，正确的写法如下：
-- 正确示例：使用HAVING过滤聚合结果
SELECT
user_id,
SUM(order_amount) AS total_amount
FROM order_table
GROUP BY user_id
HAVING SUM(order_amount) > 100 -- HAVING支持聚合函数过滤
ORDER BY total_amount DESC;
总结
数据库查询中，聚合函数的执行顺序始终在ORDER BY排序之前，排序操作是针对聚合计算完成后的最终结果集进行的。编写SQL时需要遵循标准执行顺序，避免在WHERE子句中使用聚合函数，需要过滤聚合结果时使用HAVING子句，这样才能保证查询逻辑正确，得到预期的结果。