GROUP BY不能用SELECT别名，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，别名仅在SELECT阶段生成，GROUP BY阶段尚未存在；MySQL允许属非标准扩展，其余数据库均严格报错。
GROUP BY 不能用 SELECT 中定义的别名，不是数据库“不支持”，而是 SQL 执行顺序决定了它根本还没出现——在 GROUP BY 阶段，那个别名连名字都没被注册过。
SQL 执行顺序决定了别名不可见
标准 SQL 解析顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。别名只在 SELECT 阶段才绑定进符号表，而 GROUP BY 在它之前就完成了字段解析和分组逻辑校验。
所以像下面这种写法，在 PostgreSQL、Oracle、SQL Server、Hive 和 MySQL 8.0+ 严格模式下都会直接报错：
SELECT AVG(price) AS avg_p FROM products GROUP BY avg_p
错误信息通常是：Invalid column name 'avg_p' 或 ORA-00904: invalid identifier。
-
WHERE和GROUP BY都看不到SELECT里的别名，这是语义限制，不是语法松紧问题 -
ORDER BY可以用别名，因为它在SELECT之后执行 -
HAVING也不行——它虽在GROUP BY之后，但仍在SELECT之前，照样看不到别名
MySQL 为什么看起来能用？
MySQL（尤其是 5.7 以前）允许 GROUP BY avg_p 这种写法，但这属于 parser 层的非标准扩展，并非语义正确。
它本质是 MySQL 在解析时“偷看了” SELECT 列表，把别名反向映射回原始表达式。一旦你开启 ONLY_FULL_GROUP_BY 模式（MySQL 5.7+ 默认启用），或切换到其他数据库引擎，这类写法立刻失效。
- 不是“MySQL 更智能”，而是它更宽松；其他数据库选择更严谨地遵守 SQL 标准
- 依赖 MySQL 这个行为写代码，等于给迁移埋雷：换库、升级、甚至只是改个 SQL_MODE 都可能崩
- 即使在 MySQL 里，
WHERE avg_p > 100依然非法——说明它没真正“理解”别名，只是对GROUP BY做了特殊处理
替代方案怎么选？
核心原则：让 GROUP BY 看到的是“已存在的列”，而不是“还没出生的别名”。有三种常用方式：
- 重复表达式：如
GROUP BY CASE WHEN call_time > 0 THEN 1 ELSE 0 END—— 最兼容，但维护成本高；空格、括号、ELSE分支稍有差异，分组结果就错位 - 子查询提前计算并命名：外层
GROUP BY引用子查询的输出列，例如：SELECT callt, COUNT(*) FROM (SELECT CASE WHEN call_time > 0 THEN 1 ELSE 0 END AS callt FROM t) t GROUP BY callt
注意子查询必须带别名（如t），否则 MySQL 8.0+ 会报Invalid column name - CTE 更易调试：先写
WITH cte AS (SELECT ..., CASE ... AS callt FROM t) SELECT * FROM cte LIMIT 5验证中间结果是否符合预期，再加GROUP BY
容易被忽略的静默陷阱
子查询看似一劳永逸，但几个细节常导致结果偏差而非报错：
-
CASE表达式在子查询和外层必须字面完全一致：包括空格、括号位置、ELSE分支（漏写ELSE NULL，遇到NULL值会被丢弃，分组计数变少） - 子查询若漏掉
AS t别名，在 MySQL 8.0+ 和 SQL Server 中会触发解析歧义，报Invalid column name - 时间字段如
created_at直接参与分组，毫秒精度或跨时区可能导致同一天记录被切到不同组；用DATE(created_at)就必须同步写进GROUP BY DATE(created_at)
最麻烦的不是报错，而是不出错却算错——比如 ANY_VALUE() 看似绕过限制，但它不保证返回哪一行值，业务逻辑可能因此悄悄偏移。
