HAVING不能直接过滤分组内枚举值范围，需用MIN()=MAX()与COUNT(DISTINCT)组合判断：要求MIN和MAX均在目标集内，且去重数等于目标集大小。
HAVING 不能直接过滤“分组内只含指定枚举值”，它只过滤分组聚合结果
很多人误以为 HAVING 能像 WHERE 那样对原始行做条件筛选，其实它作用于分组后的聚合结果。比如你想查“每个部门里员工岗位只包含 'ENGINEER' 和 'MANAGER'，且不能有其他值”，HAVING job IN ('ENGINEER', 'MANAGER') 是无效的——因为 job 在 HAVING 中不单值存在（除非加了 MIN(job) = MAX(job) 这类技巧）。
用 MIN() = MAX() + COUNT(DISTINCT) 判断组内枚举值是否严格受限
核心思路：若某组中所有枚举值都落在目标集合内，且没有多余值，则该组的最小值和最大值必然都在目标集中，且去重计数等于目标集大小（或更小，需配合排除逻辑）。
例如，查订单表 orders 中“每个用户下的支付方式仅限 'alipay' 和 'wechat'”：
'alipay'
-
HAVING COUNT(CASE WHEN payment_method NOT IN ('alipay', 'wechat') THEN 1 END) = 0—— 确保无非法值 - 再叠加
COUNT(DISTINCT payment_method) = 2（如需“恰好两种”）
遇到 NULL 或空字符串时，COUNT(DISTINCT) 行为容易出错
COUNT(DISTINCT column) 会自动忽略 NULL，但不会忽略空字符串 ''——这两者语义可能相同，却在分组判断中被当作不同值。
常见陷阱：
- 字段含
NULL：用COUNT(CASE WHEN col IS NULL THEN 1 END)单独统计，必要时在HAVING中约束为 0 - 字段含
''：先在GROUP BY前用NULLIF(col, '')统一转为NULL，避免干扰去重计数 - 混合使用时，推荐统一清洗：
COALESCE(NULLIF(payment_method, ''), 'UNKNOWN')再参与判断
替代方案：用 NOT EXISTS + 窗口函数更清晰，但兼容性差
某些场景下硬套 HAVING 反而绕弯。PostgreSQL / SQL Server 支持窗口函数，可先标记每组是否含非法值：
SELECT DISTINCT user_id
FROM (
SELECT user_id,
COUNT(*) FILTER (WHERE payment_method NOT IN ('alipay','wechat'))
OVER (PARTITION BY user_id) AS bad_cnt
FROM orders
) t
WHERE bad_cnt = 0;
MySQL 8.0+ 也可用类似写法，但 MySQL 5.7 及更早版本只能退回子查询 + NOT EXISTS 模式。这种写法逻辑直白，但性能取决于索引和数据量——特别是当分组键基数高时，HAVING 方案通常更快。
真正难的不是写出语法，而是想清楚：“只包含 A 和 B”到底指「不能有 C/D/…」，还是「可以只有 A、只有 B、或两者都有」，抑或「必须两者都有」——这个语义边界一旦模糊，HAVING 条件就很容易漏判或误杀。
