group by语法上直接禁止子查询，因解析阶段即报错；必须通过派生表、cte或join提前物化子查询结果为确定列后才能分组。
GROUP BY 语法上直接禁止子查询
所有主流数据库（MySQL 8.0+、PostgreSQL、SQL Server）在解析阶段就拒绝 GROUP BY 中出现任何子查询——不是“不推荐”，是硬性报错。比如写 GROUP BY (SELECT dept_name FROM departments WHERE id = e.dept_id)，MySQL 直接抛 ERROR: subquery in GROUP BY is not allowed，PostgreSQL 是 subquery in GROUP BY is not allowed，SQL Server 明确提示 The GROUP BY clause cannot contain a subquery。这不是执行时逻辑问题，是词法/语法校验过不去。
执行顺序决定了相关子查询根本不可用
GROUP BY 发生在 FROM → WHERE → GROUP BY → HAVING → SELECT 链路的早期阶段，而相关子查询依赖外层别名（如 e.user_id）才能运行。但此时外层查询尚未完成绑定，符号表里压根没有 e 这个别名。更致命的是：分组动作还没发生，子查询却想用分组键去查数据，形成逻辑死锁。
- 即使绕过语法检查（如某些 MySQL 5.7 宽松 parser），运行时也会报
Unknown column 'e.user_id' in 'where clause' - 优化器无法推导数据流方向，尤其当子查询本身还含聚合（如
SELECT COUNT(*) FROM orders WHERE user_id = e.id）时，双重依赖让计划彻底失效
想按子查询结果分组，必须提前物化
唯一可行路径是把子查询结果变成一个“已知列”，再交给 GROUP BY 处理。三种可靠方式：
-
派生表：把子查询塞进
FROM，例如SELECT cnt, COUNT(*) FROM (SELECT u.id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS cnt FROM users u) t GROUP BY cnt—— 注意内层必须单行返回，否则FROM阶段就报错 -
CTE：语义最清晰，
WITH user_orders AS (SELECT u.id, COALESCE((SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id), 0) AS cnt FROM users u) SELECT cnt, COUNT(*) FROM user_orders GROUP BY cnt——COALESCE防止NULL导致分组异常 -
JOIN 替代：如果子查询只是查关联表字段（如部门名），优先改用
LEFT JOIN departments d ON e.dept_id = d.id GROUP BY d.dept_name，性能远优于每行触发一次子查询
最容易被忽略的静默陷阱
即便用派生表把子查询固化成列，仍可能出问题：
- 子查询返回
NULL时，所有NULL被归为同一组，但业务上你可能希望“无订单用户”单独成组 - 外层
GROUP BY的列名若和子查询中字段重名（比如都叫id），不加表别名会导致歧义，MySQL 8.0+ 直接报Column 'id' in field list is ambiguous - 子查询里写了
ORDER BY（哪怕没LIMIT），部分数据库会拒绝解析或静默忽略，结果不可控
