group by字段顺序决定分组层级结构，如group by dept, role表示“部门→岗位”嵌套分组，影响语义、默认输出顺序、索引命中及order by复用；顺序错位会导致报表维度错乱、索引失效与语义漂移。
GROUP BY字段顺序决定分组键结构，不是“随便换着写”
它不改变最终分组行数（比如 GROUP BY a, b 和 GROUP BY b, a 都产生最多 COUNT(DISTINCT a) × COUNT(DISTINCT b) 行），但直接定义了“先按什么分、再在子组里按什么分”的层级关系。这影响结果语义、默认输出顺序、索引是否命中，以及后续 ORDER BY 是否能复用。
- 写成
GROUP BY dept, role：逻辑上是「部门 → 岗位」嵌套结构，每条结果代表“某部门下的某岗位” - 写成
GROUP BY role, dept：变成「岗位 → 部门」，同个岗位下不同部门被归为同一层，报表维度就对不上了 - 当某字段含大量
NULL，顺序会影响NULL被挂在哪一层——GROUP BY status, category中，status IS NULL的所有记录会先被聚成一组，再按category细分；反过来则先按category分，NULL可能散落在多个大组里
MySQL 里 GROUP BY 顺序和索引能否加速强相关
MySQL 严格依赖索引最左前缀匹配 GROUP BY 列顺序。索引 (region, dept, role) 只能加速 GROUP BY region 或 GROUP BY region, dept，但对 GROUP BY dept, role 完全无效——哪怕三个字段全在索引里，中间跳过 region 就不行。
- 高频查询是
GROUP BY date, product_id？索引必须建为(date, product_id)，不能反过来 - 如果同时要
ORDER BY date, product_id，这个索引还能顺便避免Using filesort - 想支持
GROUP BY product_id, date？得额外建一个(product_id, date)索引，没法复用
ORDER BY 不继承 GROUP BY 顺序，显式写才靠谱
很多人以为写了 GROUP BY a, b，结果就自动按 a, b 排好序了。不是。SQL 标准不保证这点，MySQL 5.7 以前可能碰巧按这个顺序输出，但那是实现细节，升级或换数据库就崩。一旦加了 ORDER BY，引擎就得重排——除非索引刚好匹配。
-
GROUP BY a, b ORDER BY a, b：索引(a, b)可覆盖，无排序开销 -
GROUP BY a, b ORDER BY b, a：索引(a, b)失效，必触发Using filesort -
GROUP BY a, b ORDER BY a：看似只排一列，但优化器仍可能因执行计划选择先分组再全量排序，尤其当b值稀疏、聚合函数计算重时
SELECT 列顺序和 GROUP BY 顺序错位，前端解析容易出错
这不是语法错误，但会导致下游消费混乱。比如导出 CSV 或对接 BI 工具时，字段顺序和预期维度不一致，role 列本该在第二位却跑到第四位，脚本解析直接错位。
- 业务语义是“按部门看各岗位数据”，就固定用
GROUP BY dept, role，且SELECT也按此顺序列出字段 - 别为了“让 NULL 出现在前面”临时调换顺序，用
COALESCE(dept, 'unknown')替换更安全 - 应用层做归并排序时，字段顺序错位会让
sorted(rows, key=lambda x: (x[0], x[1]))拿错索引
真正麻烦的不是语法报错，而是字段顺序引发的语义漂移和索引失效——这两点在上线后很难被监控发现，往往要等报表数字对不上才排查。
