GROUP BY本身不保证排序，必须显式使用ORDER BY；ORDER BY字段须在SELECT或GROUP BY中，否则报错；执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY。
GROUP BY 本身不排序，ORDER BY 才管顺序
GROUP BY 只负责把行按指定列归组，不承诺任何输出顺序。你看到“好像按某个字段排好了”，只是碰巧——换索引、加 WHERE、升级小版本，结果就可能乱。这不是失效，是根本没这功能。必须显式写 ORDER BY 控制最终结果行的排列。
ORDER BY 字段必须出现在 SELECT 或 GROUP BY 中
SQL 标准要求：ORDER BY 后的每个字段，要么是 GROUP BY 子句里的列（如 user_id），要么是聚合表达式结果（如 COUNT(*)、MAX(created_at)）。否则 MySQL 5.7+、PostgreSQL 等会直接报错：
Expression #1 of ORDER BY clause is not in GROUP BY clause
常见错误写法：
-
SELECT user_id, status FROM orders GROUP BY user_id ORDER BY status——status既没分组也没聚合，非法 -
SELECT dept_id FROM employees GROUP BY dept_id ORDER BY name——name不在SELECT里，也不在GROUP BY中
正确做法：补进分组，或用聚合兜底，例如 ORDER BY MAX(created_at) DESC。
别名在 ORDER BY 中可能不被识别
SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，所以 ORDER BY 理论上能看到 SELECT 中定义的别名。但 MySQL（尤其旧版本或嵌套复杂时）对别名解析不稳定。
风险写法：SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id ORDER BY cnt DESC —— 在某些场景下静默失效。
稳妥写法：
- 直接复写聚合表达式：
ORDER BY COUNT(*) DESC - 或包一层子查询：
SELECT * FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t ORDER BY cnt DESC
多字段排序时 NULL 和 collation 会悄悄破坏顺序
当 ORDER BY 涉及多个字段，且其中存在大量 NULL 值，不同数据库默认处理方式不同（MySQL 默认 NULLS LAST，PostgreSQL 默认 NULLS FIRST），容易导致“看起来乱”。更隐蔽的是字符集校对规则（collation）不一致：
Illegal mix of collations: 'utf8mb4_unicode_ci' and 'utf8mb4_general_ci'
这种错误常在 JOIN 后 GROUP BY 字符串字段时爆发。临时解法是在 GROUP BY 和 ORDER BY 中都显式加 COLLATE，比如：
ORDER BY category COLLATE utf8mb4_unicode_ci, COUNT(*) DESC
长期建议统一表字段的 collation，避免靠临时强制转换硬扛。
