GROUP BY + COUNT 能筛选“全满足”ID，因先按ID分组，再用COUNT(CASE WHEN条件 THEN 1 END)统计达标行数，与COUNT(*)比较是否相等；WHERE只能筛单行条件，无法表达集合全量约束。
GROUP BY + COUNT 为什么能筛出“全满足”的ID
直接用 WHERE 只能筛“至少满足一个条件”的记录，而“该ID的所有记录都满足某组条件”本质是集合包含问题——得先按 ID 分组，再看每组里符合条件的行数是否等于该ID的总行数。这时候 COUNT 就成了计数器，不是统计总数，而是统计“达标项数”，再和分组内总行数比对。
用条件聚合（CASE WHEN）统计达标数量
别在 HAVING 里直接写多个 AND 条件，那还是单行逻辑。正确做法是：在 COUNT 里嵌套 CASE WHEN，把每个条件转为 1/0，再求和。比如要找同时满足 status = 'active' 且 type IN ('A', 'B') 的 ID：
SELECT id
FROM orders
GROUP BY id
HAVING COUNT(CASE WHEN status = 'active' AND type IN ('A', 'B') THEN 1 END) = COUNT(*);
注意点：
-
COUNT(CASE ... THEN 1 END)只统计满足条件的行，NULL被自动忽略 -
COUNT(*)是该id组的总行数，不能写成COUNT(id)（万一有NULL就错） - 如果条件涉及多列组合（如 (a,b) 必须同时为 (1,2) 或 (3,4)），用
(a,b) IN ((1,2), (3,4))更安全，避免漏掉 NULL 情况
当条件分散在不同行时，用 SUM 替代 COUNT 更直观
比如要求一个用户必须有“登录日志”和“支付日志”两条记录（不同 log_type），这时单行永远无法同时满足两个值，必须跨行判断。用 SUM 配合布尔转整型更清晰：
SELECT user_id FROM user_logs GROUP BY user_id HAVING SUM(log_type = 'login') >= 1 AND SUM(log_type = 'payment') >= 1;
MySQL 中布尔表达式返回 1/0，PostgreSQL 需写 SUM(CASE WHEN log_type = 'login' THEN 1 ELSE 0 END)。关键区别：
- 这里不是要求“所有行都满足”，而是“至少有一行满足每个条件” → 用
>= 1，不是等号 - 若要求“恰好各有一条”，才用
= 1；但业务上“至少一条”更常见 - 别用
COUNT(DISTINCT log_type)代替，它无法区分“一条 login + 一条 payment”和“两条 login”，会误判
性能与 NULL 的坑：WHERE 预过滤比 HAVING 硬扛强得多
如果表很大，又只关心某几个 status 值，千万别把全表塞进 GROUP BY。先用 WHERE 把无关数据剔除：
SELECT id
FROM orders
WHERE status IN ('active', 'pending') -- 先缩小范围
GROUP BY id
HAVING COUNT(CASE WHEN status = 'active' THEN 1 END) = COUNT(*);
否则 GROUP BY 会为每个 ID 建临时分组，含大量无效数据，慢且内存爆。另外，如果字段可能为 NULL，CASE WHEN col = 'X' THEN 1 END 对 NULL 行完全不计数，而 COUNT(*) 仍会计，导致等式永远不成立——这时候得明确补上 IS NOT NULL 判断。
