having 只能筛选异常分组数量，无法查看组内明细；需用窗口函数补充均值、极值、时间等上下文，并用 row_number() 定位最可疑记录，同时注意预过滤无效数据和 null 分组干扰。
直接用 HAVING 就能快速筛出记录数异常的分组，但真正要定位“为什么异常”，得靠窗口函数补上明细上下文——比如该组均值、最近一条时间、最大最小值是否离谱。
为什么 HAVING 不能单独搞定异常分组定位
它只能告诉你“这个分组 COUNT(*) 太小/太大”，但看不到组内数据长什么样。比如 HAVING COUNT(*) 找出商品类目下只有 1 条商品的组，可你不知道那条商品是刚上架、还是价格为 0、还是创建时间是 1970 年——这些才是异常根因。
-
HAVING后无法直接访问原始行字段（如price、create_time），必须配合子查询或 CTE 才能拉回明细 - 如果只依赖
COUNT(*)，会漏掉“数量正常但内容全错”的情况：比如某用户组有 50 条订单，但amount全是NULL或全是999 - 数据库对
HAVING中非聚合字段的容忍度不一：PostgreSQL 要求所有非聚合字段必须出现在GROUP BY，MySQL 开启ONLY_FULL_GROUP_BY后也一样
用窗口函数给每组打“健康快照”
在子查询里用 OVER(PARTITION BY group_col) 算出每组的关键统计量，再回到外层 WHERE 过滤。这样既保留明细，又带上了组级洞察。
- 查出订单量突增但平均金额暴跌的用户：
AVG(amount) OVER (PARTITION BY user_id)和COUNT(*) OVER (PARTITION BY user_id)一起算，再加WHERE cnt > 10 AND avg_amt - 识别“空值集中爆发”的分组：用
AVG(CASE WHEN city IS NULL THEN 1.0 ELSE 0.0 END) OVER (PARTITION BY region)算空值率，比单看COUNT(*)更准 - 避免标准差失真：组内少于 5 行时
STDDEV()不可靠，可先加条件COUNT(*) OVER (PARTITION BY x) >= 5再算，否则跳过该组
ROW_NUMBER() + PARTITION BY 定位组内最可疑的那条记录
当一组数据整体分布可疑，但你想快速看到“最离谱的那条”来人工核验，ROW_NUMBER() 是最快路径。
- 找每组金额最高的订单：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC, order_id DESC)—— 加order_id DESC防止同金额时排序不稳定 - 排除时间戳完全一致导致的随机取值：如果
create_time精确到秒且存在并发写入，仅靠它排序可能每次结果不同，务必补一个确定性字段（如主键、日志序列号） - 别直接
WHERE rn = 1就删数据：先加上原始字段（如user_id,amount,create_time）导出检查，确认是脏数据再处理
最容易被跳过的点是：没在窗口计算前用 WHERE 排除明显无效数据（比如 status = 'deleted'），导致异常信号被噪声稀释；也没验证 PARTITION BY 字段本身是否含大量 NULL——那会把所有 NULL 归成一组，干扰判断。
