GROUP BY聚合结果需显式暴露分组键和聚合值才能被外层JOIN引用；LEFT JOIN后WHERE过滤右表字段会剔除NULL行，等效INNER JOIN，应将条件移至ON子句。
GROUP BY聚合结果怎么传给外层JOIN？
不能把聚合子查询当普通表直接用字段名引用，必须显式暴露分组键和聚合值。比如想查“每个用户最近一笔订单时间”，子查询里得写SELECT user_id, MAX(created_at) AS last_order_time FROM orders GROUP BY user_id，外层才能用t.last_order_time——少一个AS别名，外层就报“column does not exist”。
为什么LEFT JOIN后加WHERE过滤右表字段会丢数据？
这是最容易踩的语义陷阱：一旦在WHERE里写o.status = 'paid'，哪怕用了LEFT JOIN，数据库也会把它当成INNER JOIN处理，没订单的用户直接消失。
- 正确做法是把条件挪到
ON子句里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果必须在聚合后筛，就在子查询里做：
WHERE o.created_at >= '2026-01-01'下推，而不是等关联完再WHERE - 聚合子查询中用
HAVING筛组时，别指望它能控制外层行数——它只决定哪些组进结果，不决定哪些主表行保留
子查询里GROUP BY后怎么安全引用外层字段？
相关子查询（比如SELECT (SELECT MAX(created_at) FROM orders WHERE user_id = u.id)）每行都触发一次全表扫描，10万用户就是10万次查询。这不是慢，是灾难。
- 改用派生表或CTE，把聚合提前固化：
FROM users u JOIN (SELECT user_id, MAX(created_at) AS last_time FROM orders GROUP BY user_id) t ON u.id = t.user_id - 确保
user_id在orders表上有索引，否则子查询本身就会扫全表 - MySQL 5.7以下不支持CTE？那就用
FROM (SELECT ...) AS t，但注意临时结果不走索引，务必让子查询足够轻量
HAVING不能直接嵌套在WHERE里，怎么绕过语法限制？
写WHERE id IN (SELECT id FROM t GROUP BY id HAVING COUNT(*) > 1)在PostgreSQL或MySQL 8.0+会直接报错“syntax error at or near HAVING”。标准SQL不允许HAVING出现在子查询的WHERE上下文里。
- 必须多包一层：
WHERE id IN (SELECT id FROM (SELECT id FROM t GROUP BY id HAVING COUNT(*) > 1) AS _) - 更推荐CTE写法，逻辑清晰且优化器更容易物化中间结果：
WITH dup_ids AS (SELECT id FROM t GROUP BY id HAVING COUNT(*) > 1) SELECT * FROM users WHERE id IN (SELECT id FROM dup_ids) - HAVING里的条件不能用别名，比如
HAVING order_cnt > 1会失败，得写HAVING COUNT(*) > 1
真正卡住性能的往往不是语法写错，而是聚合子查询里漏了索引、带了SELECT *、或者让HAVING去筛本该由WHERE提前拦下的数据。先跑EXPLAIN看子查询是不是走了ref或range，再确认外层JOIN的rows估算值是否接近聚合后行数——这两点对了，才说明“先聚后关”真生效了。
