GROUP BY 不能用 AS 别名，因 SQL 执行顺序中 GROUP BY（第5步）早于 SELECT（第7步），别名尚未生成；MySQL 虽有特例支持，但 PostgreSQL、Oracle 等严格遵循标准，跨库应使用原始列名、重复表达式或子查询。
GROUP BY 不能用 AS 别名，不是语法限制，而是 SQL 执行阶段决定的——别名在它执行时根本还不存在。
GROUP BY 执行时，SELECT 还没跑完
SQL 不是按书写顺序执行的。真实执行顺序里，GROUP BY 在 SELECT 之前就完成了。这意味着：
-
SELECT user_id, COUNT(*) AS cnt中的cnt是在第 7 步才定义的 -
GROUP BY属于第 5 步，此时连COUNT(*)的结果都还没聚合出来，更别说cnt这个别名了 - 所以
GROUP BY cnt必然报错：ERROR: column "cnt" does not exist
MySQL 为什么看起来能用别名？
MySQL 是个特例，它在解析阶段做了“别名前移”处理，让 GROUP BY 能“看到” SELECT 里的别名。但这不是标准行为：
- PostgreSQL、SQL Server、Oracle、Hive、Doris 等全部严格遵循执行顺序，
GROUP BY一律不认别名 - 即使你在 MySQL 里写通了，换到其他数据库立刻失败，迁移成本高
- MySQL 8.0+ 对某些复杂表达式（比如嵌套子查询中的别名）也可能退回到标准行为
替代方案：哪些写法真正跨库兼容
别名不能用，但需求要满足。可靠做法只有三种：
- 直接写原始列名：
GROUP BY user_id—— 最安全，但无法用于计算列 - 重复整个表达式：
GROUP BY CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END—— 可读性差，但 100% 兼容 - 用子查询或 CTE 提前生成别名字段：
SELECT cnt FROM (SELECT COUNT(*) AS cnt FROM logs) t GROUP BY cnt—— 多一层嵌套，但逻辑清晰、无歧义
ORDER BY 为什么可以？但它也不该依赖
ORDER BY 是唯一一个在标准中“可能”接受别名的子句，因为它的执行顺序在 SELECT 之后（第 9 步）。但仍有风险：
- Oracle 和旧版 MySQL（5.6 及更早）对
ORDER BY别名支持也不稳定 - 使用位置序号更稳妥：
ORDER BY 2表示按 SELECT 列表中第 2 个字段排序 - 一旦 SELECT 列顺序调整，
ORDER BY 2就会悄无声息地指向错误字段——所以优先写明列名或表达式
真正容易被忽略的是：**别名不是变量，也不是作用域内的绑定标识符；它只是输出时的标签，在查询中间过程里完全不可见。** 任何试图在 WHERE、GROUP BY、HAVING 中引用它的写法，本质上都是在和 SQL 的生命周期对抗。
