group by不保证结果顺序，必须显式使用order by排序；执行顺序为from→where→group by→having→select→order by→limit；分组内排序需用窗口函数如row_number()。

GROUP BY本身不保证任何顺序

执行 GROUP BY 后的结果集顺序是未定义的——MySQL、PostgreSQL、SQL Server 都不承诺分组结果按某列自然排列。哪怕你观察到某次查询“看起来有序”，换索引、加 WHERE、升级小版本，都可能突然变乱。这不是 bug，是标准行为。

常见错误现象：同一语句在开发环境看似按 category 分组后顺序稳定，上线后分页列表错位、导出 Excel 重复或漏项；或者用 GROUP_CONCAT 拼接时字段顺序每次不同。

• 不要依赖插入顺序、主键顺序、聚簇索引物理存储顺序
• GROUP BY 只负责聚合逻辑，不参与排序逻辑
• 即使表有主键，GROUP BY id 也不等于“按 id 排序输出”

必须显式写 ORDER BY，且放在 GROUP BY 之后

SQL 执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。所以 ORDER BY 必须写在 GROUP BY 之后，且只能引用 SELECT 列中的字段（或其别名），不能引用原始表中未出现在 SELECT 中的列。

正确写法示例：

SELECT category, COUNT(*) AS cnt
FROM products
GROUP BY category
ORDER BY cnt DESC, category ASC;

错误写法示例（语法报错或行为不可靠）：

• ORDER BY created_at —— 若 created_at 不在 SELECT 或 GROUP BY 中，多数数据库会拒绝执行
• ORDER BY 1 —— 虽然部分数据库支持位置序号，但可读性差、易随 SELECT 改动而失效
• 把 ORDER BY 写在 GROUP BY 前面 —— 语法错误

分组内子顺序也要控制？用窗口函数或子查询

如果需求是“每个分组内部还要按某字段排序（比如每类商品取最新上架的前3个）”，GROUP BY + ORDER BY 无法解决——它只控制最终结果行的顺序，不控制每个分组内部聚合前的行序。

这时得换思路：

• 用 ROW_NUMBER() OVER (PARTITION BY category ORDER BY created_at DESC) 先标序号，再外层过滤 WHERE rn
• 或用相关子查询：(SELECT ... FROM products p2 WHERE p2.category = p1.category ORDER BY created_at DESC LIMIT 3)（注意 MySQL 8.0+ 才支持 LIMIT 在子查询中）
• 避免用 GROUP_CONCAT(... ORDER BY ...) 依赖隐式排序，显式写 GROUP_CONCAT(name ORDER BY updated_at DESC)（MySQL 特有语法，其他库不兼容）

ORDER BY 字段含 NULL 或类型混杂时更易乱

当排序字段存在大量 NULL，或混合了字符串和数字（如 '10' 和 '2' 当字符串排是 '10' NULL 的默认处理（NULLS FIRST / NULLS LAST）也不同，会导致跨库迁移后顺序突变。

稳妥做法：

• 统一补默认值：COALESCE(sort_field, 'zzz') 或 COALESCE(sort_field, 999999)
• 强制类型转换：ORDER BY CAST(weight AS UNSIGNED)（防字符串权重 '10'
• 显式声明空值位置：ORDER BY status NULLS LAST, id（PostgreSQL/Oracle 支持；MySQL 不支持，需用 IFNULL(status, 'z') 替代）

真正容易被忽略的点：分组 + 排序组合下，索引是否覆盖 GROUP BY 列和 ORDER BY 列。如果没索引，大表分组后再排序可能触发临时磁盘文件排序，性能断崖下跌——这比顺序乱更早暴露问题。