ORDER BY在GROUP BY后只按第一个字段生效，是因为SQL标准要求排序字段必须出现在GROUP BY中或为聚合结果，否则数据库会报错或返回不确定值。
GROUP BY 后 ORDER BY 为什么只按第一个字段生效？
不是 ORDER BY 失效，而是你没告诉它「对谁排序」。SQL 标准要求：当使用 GROUP BY 时，ORDER BY 的字段必须出现在 SELECT 列表中（除非是聚合函数结果），且不能依赖非分组、非聚合的列——否则多数数据库（如 MySQL 5.7+、PostgreSQL、SQL Server）会直接报错或静默忽略。
常见错误现象：SELECT user_id, status, COUNT(*) FROM orders GROUP BY user_id ORDER BY status, created_at —— 这条在 PostgreSQL 里直接报 column "status" must appear in the GROUP BY clause or be used in an aggregate function；MySQL 8.0 默认模式下也会拒绝执行。
- 必须确保
ORDER BY中每个字段，要么是GROUP BY中的列（如user_id），要么是聚合结果（如COUNT(*)、MAX(created_at)） - 如果想按「每组内最新时间」排序，得写成
ORDER BY MAX(created_at) DESC，而不是裸写created_at - MySQL 5.7 以前允许“隐式分组”，但那是 bug 级别的宽松行为，升级后大概率崩，别依赖
想按多个业务字段排序，但它们不在 GROUP BY 里怎么办？
典型场景：统计每个用户的订单数，但想按「用户等级 + 最近下单时间」排序。用户等级在 users 表，下单时间在 orders 表，而你只 GROUP BY orders.user_id —— 这时不能直接 ORDER BY users.level, MAX(orders.created_at)，因为 users.level 没参与分组，也没聚合。
解法只有一个：把需要排序的维度，提前收进分组逻辑里。常用方式是 JOIN 后再 GROUP，或用子查询/CTE 先聚合再关联。
- 推荐写法：先聚合订单数据，再 JOIN 用户信息，最后排序：
SELECT o.user_id, u.level, o.cnt, o.last_order FROM (SELECT user_id, COUNT(*) AS cnt, MAX(created_at) AS last_order FROM orders GROUP BY user_id) o JOIN users u ON o.user_id = u.id ORDER BY u.level DESC, o.last_order DESC - 别在
GROUP BY后直接JOIN再ORDER BY关联表字段——那会扩大分组粒度，结果错乱 - 如果只是临时看数据，用窗口函数更干净：
SELECT DISTINCT user_id, FIRST_VALUE(level) OVER (PARTITION BY user_id), ...，但注意这不是替代 GROUP BY 的方案
ORDER BY 里混用聚合和非聚合字段，性能会怎样？
只要语法合法（即所有 ORDER BY 字段都满足 SQL 标准约束），数据库就能执行，但性能差异很大。核心在于：排序字段是否能走索引。
-
ORDER BY user_id, COUNT(*)：如果user_id有索引，前半部分可利用；但COUNT(*)是计算值，无法索引，整体排序仍需临时文件 -
ORDER BY MAX(created_at)：即使created_at有索引，MAX()也要等分组完成才能算，无法提前剪枝 - 真正能加速的，是把排序逻辑「下推」到聚合前，比如：
SELECT user_id, COUNT(*) FROM orders WHERE created_at > '2024-01-01' GROUP BY user_id ORDER BY user_id—— 这时WHERE和ORDER BY都可能命中索引
MySQL 8.0 和 PostgreSQL 对 GROUP BY + ORDER BY 的处理差异
表面都是标准 SQL，但细节坑不少。最常踩的是 MySQL 的 sql_mode 设置和 PostgreSQL 的严格性。
- MySQL 8.0 默认开启
ONLY_FULL_GROUP_BY，一旦关掉（比如为了兼容旧代码），ORDER BY status可能返回任意一行的status值，毫无确定性 - PostgreSQL 从不妥协：哪怕你加了
status到SELECT，只要没进GROUP BY或没聚合，就报错 - SQLite 是个例外，允许非标准写法，但结果不可靠——别拿它当开发环境验证逻辑
- 跨数据库移植时，统一用「GROUP BY 所有非聚合 SELECT 字段」最安全，哪怕看起来冗余
GROUP BY 和 ORDER BY 的交界处，本质是「分组语义」和「排序需求」的对齐问题。最容易被忽略的，是以为排序字段只要在 SELECT 里出现就行——其实它还必须和分组键有确定性关系，否则数据库根本不知道你想排哪一行的值。
