HAVING 适合筛选分组内异常值，因其作用于聚合后结果；WHERE 因未分组无法统计每组异常数；需明细时用窗口函数打标再过滤；复杂逻辑宜用 EXISTS 子查询。
用 HAVING 筛选分组内异常值最直接
想判断某个分组里有没有异常数据，比如订单表中每个用户的订单金额是否出现负数、空值或超出合理范围，HAVING 是比 WHERE 更合适的工具——因为它是作用于聚合结果之后的，能天然处理“分组内是否存在”的逻辑。
常见错误是试图在 WHERE 中写 COUNT(CASE WHEN amount 0，这会报错或逻辑错位：WHERE 执行时还没分组，也没聚合，根本无法统计每组的异常数量。
- 正确做法：先
GROUP BY user_id，再用HAVING检查聚合结果，例如HAVING MAX(CASE WHEN amount -
MAX()或BOOL_OR()（PostgreSQL）比SUM()更安全：避免因重复行导致计数膨胀误判 - MySQL 8.0+ 可用
HAVING COUNT(CASE WHEN amount 0，但注意COUNT(NULL)自动忽略，语义清晰
用窗口函数标记异常后再分组判断
当需要同时返回“哪些组有异常”和“异常具体在哪几行”，纯 GROUP BY + HAVING 就不够用了——它只输出分组摘要，丢掉明细。这时得靠窗口函数提前打标。
典型场景：审计日志中检查每个服务名下是否有 status = 'ERROR' 的记录，并保留出错时间戳。
- 先用
MAX(CASE WHEN status = 'ERROR' THEN 1 ELSE 0 END) OVER (PARTITION BY service_name)生成每行所属分组是否含异常的标志 - 再在外层
SELECT DISTINCT service_name过滤该标志为 1 的组，或直接WHERE筛出异常行 - 注意：窗口函数不能直接出现在
HAVING中，必须套子查询或 CTE - 性能敏感时慎用：对大数据量，
PARTITION BY的开销可能高于简单分组
EXISTS 关联子查询判断分组异常更灵活
当异常判定逻辑复杂，比如“某用户存在订单金额为负，且该用户近7天还有其他订单”，用 HAVING 很难表达；EXISTS 子查询配合主表分组字段，可自然嵌套任意条件。
优势在于可复用已有业务逻辑，不依赖聚合函数，且支持多层嵌套校验。
- 写法示例：
WHERE EXISTS (SELECT 1 FROM orders o2 WHERE o2.user_id = o1.user_id AND o2.amount ，再配合 <code>GROUP BY即可 - 别漏加关联条件（如
o2.user_id = o1.user_id），否则变成全表扫描或笛卡尔积 - 某些数据库（如旧版 MySQL）对
EXISTS中的聚合或LIMIT支持有限，需实测 - 如果主表已按分组字段索引，
EXISTS效率通常优于IN或JOIN
警惕 NULL 和空字符串干扰异常判断
实际数据里，NULL 常被当作“缺失”而非“正常”，但 SQL 中 amount = NULL 永远为 false，amount != -1 对 NULL 也返回 unknown，容易漏判。
同样，空字符串 '' 在数值字段中可能转成 0，掩盖真实问题。
- 显式检查
amount IS NULL或COALESCE(amount, 0) ，别依赖默认转换 - 字符串类异常（如状态码为空）要用
status IS NULL OR TRIM(status) = ''，避免空格干扰 - 用
CASE WHEN统一归类：把NULL、空、非法值都映射到同一标记值，再聚合判断 - 建表时加
NOT NULL和CHECK约束，比事后查更可靠
HAVING 写法看着最短，但一旦要回溯异常原始行，就得切到窗口函数或 EXISTS；而 NULL 处理这种细节，往往在线上查了一小时才定位到。 
