GROUP BY无法识别SELECT别名是因SQL执行顺序决定的硬性限制，即FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，别名仅在SELECT阶段绑定，而GROUP BY在其之前执行，故尚未存在；MySQL属非标准例外。
GROUP BY 无法识别 SELECT 中的别名，不是你写错了，而是 SQL 执行顺序决定的——它根本还没被创建出来。
GROUP BY 阶段别名还不存在
SQL 按固定逻辑顺序执行：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。别名只在 SELECT 阶段才绑定到表达式上，而 GROUP BY 在它之前就完成了字段解析和分组键校验。所以像 SELECT COUNT(*) AS cnt FROM t GROUP BY cnt 这种写法，在 PostgreSQL、Oracle、SQL Server、Hive 等绝大多数引擎里会直接报错，例如 column "cnt" does not exist 或 ORA-00904。
MySQL 是个例外：它在 parser 层做了宽松处理，允许 GROUP BY cnt，但这属于非标准行为。一旦开启 ONLY_FULL_GROUP_BY 或迁移到其他数据库，立刻失效。
重复表达式最兼容但容易出错
把 SELECT 里的表达式原样抄进 GROUP BY，是跨库 100% 兼容的写法，适合简单计算：
GROUP BY CASE WHEN status = 1 THEN 'active' ELSE 'inactive' ENDGROUP BY DATE(created_at)GROUP BY SUBSTRING(email, 1, 3)
但要注意：
- 空格、括号、大小写、
ELSE分支必须完全一致，差一点就会导致分组逻辑错位 - 原始字段含
NULL时，若CASE没写ELSE NULL，该行会被静默丢弃，计数变少 - 表达式越长，维护成本越高，改一处漏一处的风险越大
子查询或 CTE 提前生成别名字段
这是中等以上复杂度场景的推荐做法，逻辑清晰、可调试、避免重复：
SELECT callt, COUNT(*) FROM (SELECT CASE WHEN call_time > 0 THEN 1 ELSE 0 END AS callt FROM t_annoyance) t GROUP BY callt
或用 CTE：
WITH categorized AS ( SELECT CASE WHEN call_time > 0 THEN 1 ELSE 0 END AS callt FROM t_annoyance ) SELECT callt, COUNT(*) FROM categorized GROUP BY callt
关键细节：
- 子查询必须带表别名（如
t），否则 MySQL 8.0+ 和 SQL Server 会报Invalid column name -
CASE表达式在子查询和外层必须字面完全一致，包括换行和缩进（某些 parser 对空白敏感） - CTE 不物化，性能通常与等价子查询一致，别指望它“加速”，但它支持单独运行中间步骤验证
多表 JOIN 时别名冲突更隐蔽
当 SELECT 和 GROUP BY 涉及多个表，且存在同名列（如 status 同时在 users 和 orders 中），不加表前缀会直接报“列名不明确”错误：
- ❌
GROUP BY status—— 数据库不知道你要哪张表的status - ✅
GROUP BY u.status或GROUP BY users.status - ✅ 如果用了别名，如
users u，就必须统一用u.status，不能混用users.status
同样，SELECT 中的非聚合字段也必须带前缀，并与 GROUP BY 中的写法严格一致。Laravel Query Builder 等 ORM 在严格模式下对此检查极严，漏掉一个前缀就可能触发全表扫描或语法错误。
真正难的不是选哪种方案，而是保持表达式字面一致性——哪怕多一个空格，GROUP BY 和子查询里的 CASE 就可能算出不同结果，而这种错误不会报错，只会静默错分组。
