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 自身不提供“标记”能力，只做“保留/丢弃”，这点容易被忽略。
