having 无法直接用于 z-score/iqr 异常行识别，因其仅作用于分组聚合结果，而异常检测需为每行原始数据计算动态统计基准，必须依赖窗口函数先下推均值、标准差或分位数，再用 where 进行行级过滤。
不能直接用 HAVING 计算 Z-Score 或 IQR 来过滤单条记录——它只能过滤“组”，不是“行”。想定位异常值，得先用窗口函数把统计量“带下来”，再用 WHERE 过滤。
为什么 HAVING 无法直接用于 Z-Score / IQR 异常行识别
HAVING 的作用对象是分组后的结果集，每组只返回一行聚合值（如 COUNT、AVG）。而 Z-Score（(x - μ) / σ）或 IQR 边界（Q3 + 1.5 * IQR）需要为**每一行原始数据**计算一个参考基准，这必须依赖窗口函数，而非分组聚合。
- 写成
HAVING ABS(value - AVG(value)) > 2 * STDDEV(value)：语法错误，AVG/STDDEV在HAVING中无上下文（没GROUP BY对应粒度） - 即使加了
GROUP BY id，每组只有一行，STDDEV为NULL，Z-Score 失效 -
HAVING的输出是“哪些组保留”，不是“组内哪些行异常”
正确做法：用窗口函数 + WHERE 完成行级异常标记
核心是两步：先按业务维度（如 user_id、date）用 OVER (PARTITION BY ...) 计算每行对应的均值/标准差或分位数；再在外部 WHERE 中用这些列做比较。
- Z-Score 场景（适合近似正态分布）：
WHERE ABS(value - AVG(value) OVER (PARTITION BY user_id)) > 2 * COALESCE(STDDEV_SAMP(value) OVER (PARTITION BY user_id), 0) - IQR 场景（更鲁棒，推荐）：
先在 CTE 中算出每组的q1、q3、iqr，再JOIN回原表，WHERE value q3 + 1.5 * iqr - 必须加样本量保护：
COUNT(*) OVER (PARTITION BY user_id) >= 5，否则PERCENTILE_CONT或STDDEV易失真
WHERE 和 HAVING 在异常处理中的分工要清晰
它们不是替代关系，而是协作关系。常见误用是把本该在窗口层解决的行级判断，硬塞进分组层。
-
WHERE负责：剔除明显脏数据（value IS NULL、value ）、预过滤无效分组（<code>status = 'active'） -
HAVING负责：筛选“整体异常的组”，例如某用户所有订单均值 > 10 万（HAVING AVG(amount) > 100000），或某天有效订单数 HAVING COUNT(*) ） - 混合使用示例：先
WHERE amount > 0清洗，再GROUP BY user_id，最后HAVING COUNT(*) >= 5 AND AVG(amount) BETWEEN 100 AND 5000筛可信用户组
真正容易被忽略的是：IQR 或 Z-Score 的分母（标准差、IQR）本身受异常值影响。所以首次计算前，务必用业务规则或简单阈值做粗筛（比如 WHERE amount ），否则初始统计量就被污染了——这一步没有银弹，得结合日志、监控和人工抽样确认。
