having中直接用多个and条件易误判，因它仅过滤分组聚合结果；应改用sum(case when...)等构造独立标量标记再校验，并注意补else 0、统一类型及前置where优化性能。
HAVING 里直接写多个 AND 条件为什么不行
因为 HAVING 本身只过滤分组后的聚合结果，它不支持对「每组内不同行的值做逻辑分支判断」。比如你想查「同时满足：订单数 ≥ 5 且其中至少有 2 笔金额 > 1000 的订单」的客户，光靠 HAVING COUNT(*) >= 5 AND SUM(CASE WHEN amount > 1000 THEN 1 ELSE 0 END) >= 2 是能跑通的——但一旦条件变复杂（例如「至少 1 笔是退款 + 至少 1 笔是新客首单」），纯 AND 容易漏判或误判，本质是逻辑耦合太紧。
这时候用 CASE WHEN 在 HAVING 中构造中间状态更可控。
正确写法：在 HAVING 中用 CASE WHEN 构造聚合标记
核心思路是把多条件转化为「每组一个标量值」，再统一比对。不是在 HAVING 里嵌套一堆 CASE，而是先用 SUM/MAX 等聚合函数把 CASE 结果收拢成数字标记。
-
CASE WHEN order_type = 'refund' THEN 1 ELSE 0 END→ 每笔退款记 1，求和得退款笔数 -
CASE WHEN is_first_order = 1 THEN 100 ELSE 0 END→ 首单给权重 100，避免和退款计数冲突 - 最终
HAVING SUM(CASE ...) >= 100 AND SUM(CASE ...) >= 1就能分开校验
示例：
SELECT customer_id FROM orders GROUP BY customer_id HAVING SUM(CASE WHEN order_type = 'refund' THEN 1 ELSE 0 END) >= 1 AND SUM(CASE WHEN is_first_order = 1 THEN 1 ELSE 0 END) >= 1 AND AVG(amount) > 200;
容易踩的坑：NULL、类型隐式转换和性能陷阱
CASE WHEN 分支没写 ELSE 会导致该行返回 NULL，而 SUM(NULL) 是 NULL，整个 HAVING 判定失败（注意：不是 false，是 unknown，被过滤掉）。
- 务必补
ELSE 0，尤其涉及SUM/COUNT -
CASE返回值类型要一致，比如混用字符串和数字会触发隐式转换，MySQL 可能转成 0，PostgreSQL 直接报错 - 在大表上，
HAVING无法利用索引加速，所有分组都得算完才过滤；如果条件能前置到WHERE（如先筛出order_type IN ('refund', 'new')），性能提升明显
替代方案：用窗口函数 + 外层 WHERE 更灵活？
当条件需要跨行比较（比如「最新一笔订单是退款，且倒数第二笔是首单」），HAVING + CASE 就力不从心了。这时得用子查询或 CTE 配合窗口函数：
WITH ranked AS (
SELECT customer_id,
order_type,
is_first_order,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY create_time DESC) rn
FROM orders
)
SELECT customer_id
FROM ranked
WHERE rn IN (1, 2)
GROUP BY customer_id
HAVING MAX(CASE WHEN rn = 1 AND order_type = 'refund' THEN 1 END) = 1
AND MAX(CASE WHEN rn = 2 AND is_first_order = 1 THEN 1 END) = 1;
这种写法可读性下降，但逻辑边界清晰。真正难的不是语法，是想清楚「这个条件到底属于分组内聚合判断，还是分组内行间顺序判断」——选错层级，后面全得重写。
