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 不物化数据，性能和等价子查询基本无差别，别指望它“加速”，它只帮你把逻辑拆开验证