HAVING 用于筛选分组后的聚合结果，必须与 GROUP BY 配合使用；WHERE 在分组前过滤行，不能用聚合函数，而 HAVING 可基于 COUNT、SUM 等聚合结果条件筛选，实现“全组满足某条件”的断言逻辑。
为什么直接用 WHERE 筛不出来“只属于某条件”的记录
常见误区是写 WHERE status = 'active'，但这只会查出所有 active 的记录，无法排除那些同时有 active 和 inactive 状态的用户或订单。真正要找的是：**某个分组（比如 user_id）下，所有行都满足条件，且没有一行违反条件**。这本质上是个“全量断言”问题，得靠聚合 + 逻辑判断。
用 GROUP BY + HAVING 确保组内全部满足条件
核心思路是：按业务主键（如 user_id）分组，再用 HAVING 检查该组是否“没有例外”。最稳妥的方式是统计违规行数为 0：
SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) = COUNT(CASE WHEN status = 'active' THEN 1 END);
这里 COUNT(*) 是组内总行数，COUNT(CASE WHEN ...) 只统计符合条件的行——两者相等，说明组内每一行都是 active。
- 别用
SUM(CASE WHEN status != 'active' THEN 1 ELSE 0 END) = 0，虽然语义清楚，但在某些数据库（如旧版 MySQL）中可能因 NULL 处理引发偏差 - 避免
MIN(status) = MAX(status) AND MIN(status) = 'active'，它依赖字符串比较，且当 status 有 NULL 时结果不可靠 - 如果条件是“存在且仅存在”，而字段允许 NULL，务必在
CASE中显式处理：CASE WHEN status = 'active' AND status IS NOT NULL THEN 1 END
子查询套一层只为过滤原始表，不是必须的
有人习惯写成“外层 SELECT * FROM table WHERE id IN (子查询)”，但这是画蛇添足。只要目标是查出满足“纯 active”条件的 user_id，上面的 GROUP BY + HAVING 已是最终结果；若需关联原始表取完整字段，才需要子查询或 JOIN：
SELECT o.* FROM orders o INNER JOIN ( SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) = COUNT(CASE WHEN status = 'active' THEN 1 END) ) pure_active ON o.user_id = pure_active.user_id;
注意：子查询里不能加 WHERE status = 'active'，否则就退化成普通筛选，失去“排他性”检查意义。
性能和兼容性要注意的点
这个模式在 PostgreSQL、SQL Server、MySQL 8.0+、Oracle 都能跑通，但细节有差异：
- MySQL 5.7 默认 SQL mode 下，
SELECT *和GROUP BY混用会报错，必须确保非分组字段出现在聚合函数中，或关闭ONLY_FULL_GROUP_BY - 如果数据量大，
user_id上最好有索引；status字段选择性低（比如只有 2–3 个值），单独建索引效果有限 - 用
COUNT(CASE ...)比SUM(IIF(...))或BOOL_AND()兼容性更广，PostgreSQL 的BOOL_AND(status = 'active')虽简洁，但其他数据库不支持
实际写的时候，先确认你要锁定的是哪个维度（user_id？product_id？order_id？），再决定 GROUP BY 字段——漏掉或多加一个字段，结果就完全不对了。
