having 必须紧跟 group by，不能直接用于 join 后；其作用于分组结果，仅支持聚合函数或分组字段，且 left join 中的 where 条件可能意外转为 inner join。

JOIN 后不能直接写 HAVING，必须先 GROUP BY

很多人一写 HAVING 就报错，比如 ERROR: column "xxx" must appear in the GROUP BY clause 或 In aggregated query without GROUP BY，根本原因是跳过了 GROUP BY。SQL 执行顺序固定为：JOIN → WHERE → GROUP BY → HAVING，HAVING 只能作用于分组后的结果，它看不到原始行。

正确链条只有这一种：先用 JOIN 关联表，再用 GROUP BY 明确你要按什么维度分组（通常是主表的主键或业务关键字段），最后才能在 HAVING 里写聚合条件。

• HAVING COUNT(o.id) > 5 合法，因为 COUNT() 是聚合函数，且分组字段已出现在 GROUP BY 中
• HAVING o.status = 'paid' 必报错——o.status 既没在 GROUP BY 里，也不是聚合值
• MySQL 8.0+ 默认禁止 SELECT 列中出现非分组非聚合字段；PostgreSQL、SQL Server 从不妥协，别依赖宽松模式

LEFT JOIN + HAVING 容易把 NULL 行全删掉

用 LEFT JOIN 是为了保留主表所有记录，但一旦加了 HAVING COUNT(o.id) >= 3，所有订单数为 0 的用户就彻底消失——HAVING 是“筛选组”，不是“标记组”，它只留满足条件的组，其余直接丢弃。

如果你的真实需求是“显示所有用户，并标出哪些人订单 ≥ 3”，HAVING 不适用，得换方案：

• 改用条件聚合：SUM(CASE WHEN o.id IS NOT NULL THEN 1 ELSE 0 END) AS order_cnt，然后在 WHERE 或外层 SELECT 中判断
• 用窗口函数：COUNT(*) OVER (PARTITION BY u.id) 算出每个用户的订单数，再在外层 WHERE 筛选
• 若只需 ID 列表，用 IN 或 EXISTS 子查询更轻量，也避免空值干扰

ON 和 WHERE 混用时，LEFT JOIN 会悄悄变 INNER JOIN

这是最隐蔽也最常踩的坑：在 LEFT JOIN 后写 WHERE o.status = 'shipped'，等于把所有 o.status 为 NULL 的行（即无订单用户）全过滤掉了，效果等同于 INNER JOIN。

想保留主表全部记录，同时只统计“已发货”订单数，条件必须挪到 ON 子句里：

• ✅ 正确：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'shipped'
• ❌ 错误：LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'shipped'
• 注意：如果 o.status 字段本身允许 NULL，WHERE o.status = 'shipped' 还会额外排除状态为 NULL 的有效订单行

要返回明细行又需聚合筛选？HAVING 不够用

比如“查出订单总额超 5000 的客户的所有订单明细”，这时单纯 GROUP BY c.id, o.id 再 HAVING SUM(o.amount) 没意义——SUM() 会被拆到每条订单行上算，结果恒为单笔金额，起不到筛选作用。

真正可行的路径只有两条：

• 两步走：先用子查询或 CTE 算出符合条件的 customer_id 列表（GROUP BY + HAVING），再用 IN 或 JOIN 关联回原始订单表
• 用窗口函数：在主查询里写 SUM(o.amount) OVER (PARTITION BY c.id)，然后外层 WHERE 直接筛该窗口值
• 别硬塞聚合函数进 HAVING 后还试图保留明细——执行顺序决定了它做不到

复杂点在于：分组维度必须和业务目标严格对齐，多一个字段或少一个字段，聚合结果就可能完全跑偏；而 HAVING 自身不提供“标记”能力，只做“保留/丢弃”，这点容易被忽略。