ORDER BY后跟聚合函数加DESC可实现分组后按聚合结果倒序排列，如ORDER BY COUNT(*) DESC；需注意数据库兼容性、多字段方向显式声明及NULL处理。
ORDER BY后面直接跟聚合函数加DESC
分组后按聚合结果倒序排列，最直接的方式就是在ORDER BY子句里写聚合表达式，并明确加上DESC。不加DESC默认是升序（ASC），容易误以为排对了，实际是反的。
- 允许写法：
ORDER BY COUNT(*) DESC、ORDER BY SUM(amount) DESC、ORDER BY AVG(price) DESC - 别名可用但非必须：如果
SELECT里写了SUM(sales) AS total，ORDER BY total DESC合法且可读性好，但底层仍依赖该别名对应的是聚合表达式 - MySQL宽松模式下允许
ORDER BY引用未出现在SELECT列表中的聚合表达式（如SELECT dept_id, COUNT(*) FROM t GROUP BY dept_id ORDER BY AVG(salary) DESC），但PostgreSQL/SQL Server会报错——别依赖它
多列排序时注意优先级和方向组合
按聚合结果倒序后还要加次级排序（比如销量并列时按部门名字母序），就得用逗号分隔多列，每列单独指定方向。
- 常见错误：写成
ORDER BY SUM(sales) DESC, dept_name→ 第二列没写方向，默认ASC，但容易忽略，建议显式写出ASC或DESC - 正确写法：
ORDER BY SUM(sales) DESC, dept_name ASC - 如果次级字段本身也是聚合结果（如
AVG(score)），同样要加方向：ORDER BY COUNT(*) DESC, AVG(score) ASC - 注意执行顺序：
GROUP BY→ 聚合计算 →HAVING过滤 →ORDER BY，所以所有ORDER BY里的字段必须是聚合后“存在”的值
CASE WHEN构造自定义倒序逻辑
当倒序不是数值大小，而是业务优先级（比如状态“已完成”排最前，“处理中”其次，“待提交”最后），就不能靠DESC，得用CASE WHEN生成排序键再倒排。
- 错误写法：
ORDER BY status DESC→ 按字符串字典序，“待提交”会排在“已完成”前面 - 正确思路：把状态映射为数字，再按该数字升序（小数字在前）：
ORDER BY CASE WHEN status = '已完成' THEN 1 WHEN status = '处理中' THEN 2 ELSE 3 END ASC - 如果想让“已完成”排最后，就改用
DESC：ORDER BY CASE ... END DESC -
GROUP BY里必须包含原始字段（如status），不能只写CASE表达式，否则不同状态可能被合并
用MIN/MAX模拟“首次/末次”倒序时别漏掉方向
想按每个分组的最早时间倒序（即“最新发生的组排第一”），要用MAX(created_at)而非MIN(created_at)，再加DESC——这里有两个地方容易错。
- 选错聚合函数：按“最新”排，必须用
MAX()；用MIN()得到的是最早时间，再DESC反而让最早的时间排最前 - 漏掉
DESC：写成ORDER BY MAX(updated_at)→ 默认升序，结果是“最早更新的组”在第一行 - 正确写法：
ORDER BY MAX(updated_at) DESC - 时间字段为空（
NULL）时，MAX()会跳过，不影响排序逻辑；但如果整组都是NULL，该组排序值也为NULL，通常排在最前或最后（取决于数据库NULLS FIRST/LAST设置，MySQL默认NULL最小）
真正容易被忽略的是：ORDER BY作用于整个分组结果集，它不改变分组逻辑，也不影响HAVING过滤时机。哪怕你加了LIMIT 10，也得先完成全部分组和聚合，再排序取前10——大数据量时性能瓶颈常在这里，而不是语法写错。
