GROUP BY 报 Unknown column 或 ORA-00904 是因执行顺序为 FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，别名仅在 SELECT 阶段生成，GROUP BY 无法识别；必须用原始字段、重复表达式或子查询提前计算别名。
GROUP BY 为什么报 Unknown column 或 ORA-00904？
因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，而列别名只在 SELECT 阶段才被绑定到结果集里。GROUP BY 发生在 SELECT 之前，此时数据库连这个别名都还没“看见”，自然解析失败。报错信息如 Unknown column 'dept_name' in 'group statement'（MySQL）或 ORA-00904: "dept_name": invalid identifier（Oracle）不是配置问题，而是所有主流数据库（PostgreSQL、SQL Server、Hive）的统一行为。
MySQL 允许 GROUP BY 别名，但别当真
MySQL 确实支持 GROUP BY dept_name 这种写法，但它属于非标准扩展，靠 parser 层的宽松处理实现，并非语义正确。一旦你：
- 切换数据库引擎（比如迁移到 PostgreSQL）
- 升级 MySQL 并启用严格模式（STRICT_TRANS_TABLES）
- 在子查询或视图中复用该语句
就会立刻失效。别把它当成可移植的写法，它只是个兼容性陷阱。
GROUP BY 必须用什么？三种实际选择
让 GROUP BY “看到”字段，只有三条路：
- 重复表达式：比如 SELECT CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END AS status_label FROM t GROUP BY CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END —— 最兼容，但改一处漏一处，空格或括号差一点就分组错位
- 原始列分组：直接 GROUP BY status，但业务语义可能不匹配（比如你要的是“状态分类”，不是原始数字）
- 子查询提前落地别名：推荐中等以上复杂度场景，例如：
SELECT status_label, COUNT(*)<br>FROM (SELECT CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END AS status_label FROM t) AS t_sub<br>GROUP BY status_label注意子查询必须带表别名（如
AS t_sub），否则 MySQL 8.0+ 和 SQL Server 会报错
CTE 和子查询，哪个更容易踩坑？
CTE 逻辑更清晰，但和子查询一样，逃不开执行顺序约束。真正容易被忽略的是细节一致性：
- 子查询里的 CASE 表达式，和外层 GROUP BY 或 SELECT 中的字面必须完全一致（包括空格、括号、ELSE 分支）
- 如果原始字段含 NULL，而 CASE 没写 ELSE NULL，那整行会被丢弃，导致分组计数偏少
- CTE 不物化数据，性能和等价子查询基本无差别，别指望它“加速”，它只帮你把逻辑拆开验证
