GROUP BY 无法使用 SELECT 别名，因 SQL 执行顺序为 FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，别名仅在 SELECT 阶段生成，而 GROUP BY 在其之前执行，此时别名尚未存在，故引用会报错。
GROUP BY 阶段根本看不到 SELECT 别名
因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，而别名只在 SELECT 阶段才被绑定到列上。GROUP BY 发生在 SELECT 之前，此时数据库解析器连 dept_name 这个名字都还没见过，自然报错。
常见错误现象包括：
-
ERROR 1064 (42000)（MySQL） -
column "month" does not exist（PostgreSQL） -
ORA-00904: "xxx": invalid identifier（Oracle）
这不是数据库 bug，也不是配置问题，而是所有主流引擎（PostgreSQL、Oracle、SQL Server、MySQL 8.0+）共同遵守的 SQL 标准行为。MySQL 5.7 允许是历史遗留的非标准扩展，不可依赖。
GROUP BY 中能用什么？不能用什么？
GROUP BY 只接受三类东西：原始字段、完整表达式、位置序号（如 GROUP BY 1）。它不接受任何 AS 语法，也不接受 SELECT 里定义的别名。
正确写法示例：
-
GROUP BY department✅ 原始字段 -
GROUP BY TO_CHAR(billingdate, 'YYYYMM')✅ 完整表达式（和 SELECT 中一致） -
GROUP BY 1✅ 按 SELECT 第一列分组（但易脆，改 SELECT 顺序就失效）
错误写法示例：
-
GROUP BY dept_name❌ 别名未定义 -
GROUP BY department AS dept_name❌AS在 GROUP BY 中语法非法 -
GROUP BY AVG(price) AS avg_p❌ 聚合函数 + 别名，双重无效
子查询或 CTE 是怎么“绕过”这个问题的？
它们不是绕过，而是让别名真正落地——在子查询或 CTE 的 SELECT 中定义别名后，该别名就成了内层结果集的**真实列名**，外层 GROUP BY 引用的是这个已存在的列，而非原始语句中的别名。
关键细节：
- 子查询必须带表别名（如
... FROM (SELECT ...) t），否则 MySQL 8.0+ 和 SQL Server 会报Invalid column name - CTE 中的
CASE表达式必须和子查询中字面完全一致（空格、括号、ELSE分支都不能差）；否则分组逻辑错位 - 如果原始字段含
NULL，而CASE没写ELSE NULL，该行会被直接丢弃，导致计数偏少
示例（安全写法）：
WITH billed AS ( SELECT TO_CHAR(billingdate, 'YYYYMM') AS month FROM tu_trade WHERE reportstat = 30 ) SELECT month, COUNT(*) FROM billed GROUP BY month;
别名冲突比“找不到别名”更隐蔽也更危险
当多个字段被赋予相同别名（比如 e.id AS branch_code 和 e.code AS branch_code），数据库可能不报语法错误，但会静默覆盖或混淆字段来源，导致分组粒度错误、统计口径漂移，甚至 ORM 映射失败。
典型表现：
- MySQL 报
Duplicate column name 'branch_code' - PostgreSQL 或 SQL Server 直接拒绝解析
- Laravel Query Builder 中
groupBy('e.id')却在 SELECT 中混用branch_code，造成语义断裂
修复原则很简单：每个 SELECT 字段的别名必须唯一、语义明确、与 GROUP BY 字段严格对应。别名不是装饰，是结果集结构的契约。
