group by 后 order by 有效，但需满足字段在 select 中或为聚合结果；执行顺序为 group by → 聚合 → order by；mysql 5.7+ 默认启用 only_full_group_by 严格校验。
GROUP BY 后面直接跟 ORDER BY 为什么没用
因为 SQL 执行顺序中，GROUP BY 在 ORDER BY 之前执行，但关键在于：分组后每一组只保留一行结果，而 ORDER BY 默认作用于最终结果集——它确实会生效，但你看到的“排序不生效”，往往是因为你误以为它能控制组内数据的取值逻辑（比如想让每组取最新一条记录），而实际上 ORDER BY 并不参与“选哪一行作为聚合结果”。
常见错误现象：SELECT user_id, MAX(created_at) FROM orders GROUP BY user_id ORDER BY created_at DESC 看起来想按时间倒序排用户，但结果中 created_at 是聚合后的最大值，ORDER BY created_at 其实是按这个最大值排序——语法合法，但容易误解为“组内按时间排”。
- 真正想控制“每组取最新那条完整记录”？不能靠
GROUP BY + ORDER BY直接实现，得用窗口函数或子查询 -
ORDER BY中引用的列必须出现在SELECT列表里（严格模式下），或属于分组字段，否则报错Expression not in GROUP BY - MySQL 5.7+ 默认启用
sql_mode=ONLY_FULL_GROUP_BY，会拒绝非确定性排序依赖
想按组内某字段最大/最小值排序，该怎么写
如果目标是“先按每组的最新时间降序排列用户列表”，正确做法是把聚合逻辑和排序逻辑分开表达：
SELECT user_id, MAX(created_at) AS latest_time FROM orders GROUP BY user_id ORDER BY latest_time DESC;
注意这里显式给聚合结果起了别名 latest_time，并在 ORDER BY 中引用它——这是安全且可读的方式。
- 别写
ORDER BY MAX(created_at)：虽然部分数据库支持，但可读性差，且在某些版本或 ORM 中可能被重写失败 - 如果还要查出该最新时间对应的
order_id或其他字段，GROUP BY无法保证取到同一行，必须换方案 - PostgreSQL 和 MySQL 8.0+ 支持
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，更可靠
GROUP BY + ORDER BY 出现“排序乱序”的真实原因
不是语法失效，而是你观察的字段没参与排序，或者数据库做了隐式优化。典型场景：
- 你写了
ORDER BY id，但id不在SELECT中，也不在GROUP BY列表里 → 大概率报错，或返回任意匹配行（取决于 SQL 模式） - 用了
SELECT *配合GROUP BY a→ 实际只保证a确定，其余列值无定义，ORDER BY b可能被忽略或行为不可控 - MySQL 5.7 以前允许
SELECT a, b FROM t GROUP BY a ORDER BY b，但b值是随机选取的，排序结果自然“看似无效”
验证方法：去掉 GROUP BY，单独执行 SELECT ... ORDER BY ...，看排序是否如预期；再加回分组，确认 SELECT 列是否都满足功能依赖。
替代 GROUP BY 实现“每组取 Top 1”的推荐写法
当真实需求是“每个用户最新一笔订单的完整信息”，不要硬套 GROUP BY，改用以下任一方式：
- MySQL 8.0+/PostgreSQL：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)套子查询过滤rn = 1 - 通用兼容写法：用关联子查询
WHERE created_at = (SELECT MAX(created_at) FROM orders o2 WHERE o2.user_id = o1.user_id)，注意存在并列时间时可能返回多行 - SQLite 3.25+ 支持
SELECT ... FROM orders GROUP BY user_id HAVING created_at = MAX(created_at)，但语义易混淆，不推荐
这类问题的核心陷阱在于：GROUP BY 是聚合操作，不是筛选操作；它的输出维度由分组键决定，其余字段必须通过聚合函数明确其来源逻辑。一旦忽略这点，排序就只是浮在表面的幻觉。
