GROUP BY不能直接使用SELECT别名，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，别名在SELECT阶段才生成，而GROUP BY在其之前执行，此时别名尚未存在。
为什么 GROUP BY 后不能直接用 SELECT 中的列别名
这不是 MySQL 或 PostgreSQL 的“bug”，而是 SQL 标准执行顺序决定的：GROUP BY 在逻辑上早于 SELECT 执行，所以别名在 GROUP BY 阶段还不存在。常见报错如 Unknown column 'xxx' in 'group statement' 就源于此。
尤其当子查询里用了表达式（比如 DATE(created_at)）并起了别名 day，想在外部 GROUP BY day 时就会失败。
- 别名只在
SELECT和HAVING中有效（后者也晚于GROUP BY） -
ORDER BY可以用别名，因为它是最后执行的阶段 - 不同数据库对别名的支持略有差异（如 MySQL 5.7 允许
GROUP BY引用别名，但这是非标准行为，不建议依赖）
三种可靠写法：重复表达式、派生表、CTE
核心原则：让分组依据在 GROUP BY 子句中是“可见的原始表达式”或“来自明确作用域的列”。
方式一：直接重复表达式（最轻量，适合简单场景）
SELECT DATE(created_at) AS day, COUNT(*) FROM orders GROUP BY DATE(created_at); -- 不能写成 GROUP BY day
方式二：用派生表（子查询套一层，把别名“固化”为列）
SELECT day, COUNT(*) FROM (SELECT DATE(created_at) AS day FROM orders) t GROUP BY day; -- 这里 day 是 t 的列，合法
方式三：用 CTE（语义清晰，适合复杂计算）
WITH daily_orders AS ( SELECT DATE(created_at) AS day, status FROM orders ) SELECT day, COUNT(*) FROM daily_orders GROUP BY day;
子查询嵌套过深时的典型陷阱
当多层子查询叠加（比如聚合 + 窗口函数 + 分组），容易误以为外层能引用内层别名，结果报错或返回意外结果。
- 错误示范：
SELECT x AS a FROM (SELECT 1+1 AS x) t GROUP BY a→ 报错（a不在t中） - 正确做法：要么在子查询里暴露
x，要么在外层GROUP BY写x（即GROUP BY x），而不是别名a - 如果子查询里用了
GROUP BY，那它的输出列才真正“存在”，别名必须定义在该层的SELECT中 - MySQL 8.0+ 支持 CTE 递归，但
GROUP BY仍不能跨层引用别名——作用域规则不变
性能与可维护性权衡要点
重复表达式看似冗余，但多数情况下优化器能识别并复用计算；而派生表/CTE 可能触发物化（尤其大表），需留意执行计划。
- 用
EXPLAIN检查是否出现Using temporary，这往往意味着额外开销 - 若表达式涉及函数（如
UNIX_TIMESTAMP(created_at)），重复写两次可能影响可读性，此时 CTE 更安全 - PostgreSQL 对 CTE 默认物化，MySQL 8.0+ 默认不物化（除非加
MATERIALIZED提示），行为不一致需确认版本 - 别名冲突风险：CTE 中列名若和外部表同名，
GROUP BY会优先绑定 CTE 列——这是优点，不是 bug
真正麻烦的是把别名当成“变量”去复用，SQL 里没有变量作用域的概念，只有列作用域和执行顺序约束。盯住这个边界，问题就清楚了。
