相关子查询严禁出现在GROUP BY中，因GROUP BY执行早于外层查询绑定，无法访问外层别名且逻辑死锁；正确做法是用派生表或CTE提前物化子查询结果为确定列再分组。
相关子查询根本不能出现在GROUP BY里
GROUP BY 子句只接受列名、表达式或位置编号，语法上就禁止任何子查询（包括相关子查询）——不是“不推荐”，是直接报错。PostgreSQL 报 ERROR: subquery in GROUP BY is not allowed，SQL Server 明确提示 The GROUP BY clause cannot contain a subquery，MySQL 8.0+ 同样拒绝解析。
为什么连“相关”这个特性都救不了它
相关子查询依赖外层作用域的字段（比如 u.user_id），但 GROUP BY 执行时，外层查询尚未完成绑定，符号表里根本没有 u 这个别名。更关键的是：GROUP BY 阶段还没生成分组结果，子查询却想用分组键去查数据，逻辑上形成死锁。
- 执行顺序卡死：
FROM → WHERE → GROUP BY，而相关子查询需要SELECT或HAVING阶段才具备上下文 - 即使强行绕过语法检查（如某些 MySQL 5.7 的宽松 parser），运行时也会因找不到外层别名而报
Unknown column 'u.user_id' in 'where clause' - 聚合函数和相关子查询双重依赖外层字段，会让优化器彻底无法推导数据流方向
想实现“按子查询结果分组”该怎么做
必须把子查询提前物化为一列，让 GROUP BY 能看到确定的值。有且仅有三种可靠方式：
- 重复表达式：
GROUP BY (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id)—— 语法上允许，但多数数据库会拒绝执行（报子查询返回多行），且无法索引加速 - 派生表（最常用）：
SELECT order_count, COUNT(*) FROM (SELECT u.id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u) t GROUP BY order_count—— 注意内层子查询必须确保单行返回，否则外层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 导致分组异常
最容易被忽略的陷阱
即便用派生表把子查询结果固化成列，仍可能静默出错：
- 子查询返回 NULL 时，所有 NULL 被归入同一组，但业务上你可能期望“无订单用户”单独成组
- 外层 GROUP BY 的列名若和子查询中字段重名（比如都叫
id），不加表别名会导致歧义，MySQL 8.0+ 直接报Column 'id' in field list is ambiguous - 子查询若含
ORDER BY又没配LIMIT，在派生表中会被 PostgreSQL/SQL Server 拒绝，MySQL 8.0+ 则要求显式加LIMIT 1
真正要警惕的，从来不是“怎么写才能不报错”，而是“写出来之后，NULL 怎么分组、重复值怎么收敛、空子查询结果怎么兜底”。这些细节不会在语法报错里体现，但会让统计口径偏移。
