不能在子查询中直接引用外层GROUP BY字段，须通过显式表别名关联（如WHERE o.user_id = u.user_id）；相关子查询性能差因每行触发一次执行，应优先用CTE或派生表替代。
不能在子查询里直接引用外层 GROUP BY 字段，必须显式关联；相关子查询性能极差，应优先用 CTE 替代。
子查询里 GROUP BY 后怎么引用外层字段？
子查询默认看不到外层的非聚合字段。比如想查“每个用户的订单总金额”，再在子查询里算该用户最近一笔订单时间，不能写 SELECT (SELECT MAX(created_at) FROM orders WHERE user_id = user_id)——第二个 user_id 会被解析成子查询自己的列（若存在），不是外层的。
- 正确做法是用
WHERE显式关联：WHERE o.user_id = u.user_id，其中u是外层表别名 - 如果外层没给别名，记得先加，否则容易混淆
- MySQL 5.7+ 和 PostgreSQL 在严格模式下会直接报错，而不是静默返回错误结果
为什么相关子查询一查就慢？
每行外层记录都会触发一次子查询执行。10 万用户 × 每次查 500 行订单 = 5000 万行扫描，索引也救不了。
- 避免三层以上嵌套：
SELECT (SELECT (SELECT ...))不仅难读，优化器大概率放弃重写为 JOIN - 替代方案：用
WITH把聚合提前固化，比如先WITH user_stats AS (SELECT user_id, SUM(amount) AS total, COUNT(*) AS cnt FROM orders GROUP BY user_id)，再和用户主表JOIN - MySQL 5.7 不支持 CTE？改用派生表：
FROM (SELECT ...) AS stats，但注意临时结果不走索引
GROUP BY + 子查询混用时的 NULL 和排序陷阱
聚合函数对空集合返回 NULL，但子查询单独执行为空时，整个表达式可能变成 NULL 或报错，而你未必意识到这是数据缺失导致的。
-
ORDER BY必须放在最外层，子查询里写ORDER BY会被忽略（除非配合LIMIT） - 子查询中用了
ORDER BY ... LIMIT 1，在无GROUP BY的上下文里可能返回任意一行，不是“最新”——得靠created_at DESC+LIMIT 1才稳 - 聚合结果参与排序时，别在
ORDER BY里重复写函数，比如ORDER BY COUNT(*)，部分数据库不支持，且会重复计算
真正复杂的聚合过滤，关键不在“能不能嵌套”，而在“要不要固化”。窗口函数能解决的，别硬塞进子查询；CTE 能拆清逻辑的，别堆在一层 SELECT 里。最容易被忽略的是：子查询里的 GROUP BY 一旦涉及 NULL 值，所有 NULL 会被归为同一组——这在分组统计时可能悄悄改变业务语义。
