用avg()和stddev_pop()可快速识别离群值：先计算整体均值与总体标准差，再筛选|值−均值|>3×标准差的记录；注意需用子查询或cte预计算聚合值，且过滤null以避免运算错误。
用 AVG() 和 STDDEV_POP() 快速标出离群行
离群值识别不一定要上机器学习，SQL 里靠聚合统计就能筛出明显偏离的记录。核心思路是：先算整体均值和标准差，再把每行和均值的距离换算成“几倍标准差”。通常超过 ±3σ 就值得人工复核。
注意 STDDEV_POP()（总体标准差）比 STDDEV_SAMP() 更适合做离群判定——它分母是 n 而不是 n-1，结果略小，对阈值更敏感，不容易漏掉边缘离群点。
- 必须用子查询或 CTE 先算聚合，不能在 WHERE 里直接写
AVG()—— 否则报错aggregate function calls cannot be nested - 如果字段含
NULL，AVG()和STDDEV_POP()会自动忽略，但最终过滤时得加WHERE value IS NOT NULL，否则ABS(value - avg_val) / std_val可能产出NULL，导致整行被丢弃 - 示例（PostgreSQL/MySQL 8.0+）：
SELECT id, amount<br>FROM sales<br>CROSS JOIN (<br> SELECT AVG(amount) AS avg_val, STDDEV_POP(amount) AS std_val<br> FROM sales<br> WHERE amount IS NOT NULL<br>) stats<br>WHERE ABS(amount - avg_val) > 3 * std_val<br> AND amount IS NOT NULL;
处理偏态分布时，PERCENTILE_CONT() 比均值更稳
当数据严重右偏（比如订单金额、响应时长），均值会被极值拉高，导致左侧行全被误判为“正常”。这时中位数和四分位距（IQR）更可靠。
PERCENTILE_CONT(0.5) 返回连续分布下的中位数，PERCENTILE_CONT(0.25) 和 PERCENTILE_CONT(0.75) 可算 IQR。离群边界是 Q1 - 1.5×IQR 和 Q3 + 1.5×IQR。
- MySQL 8.0+ 和 PostgreSQL 支持
PERCENTILE_CONT()，但 SQLite 和旧版 MySQL 不支持，得用自连接或变量模拟，误差大且慢 - 计算 IQR 时务必用同一窗口定义，避免因
WHERE过滤导致上下四分位数基准不一致 - 别直接用
PERCENTILE_DISC()—— 它返回实际存在的值，可能卡在某个整数上，边界不够平滑
GROUP BY 后逐组算离群，小心 NULL 分组和空组
业务上常需“按用户/地区/日期分组后找异常”，这时不能把整个表的均值套到各组头上。必须在每组内独立计算统计量，否则北京用户的高额订单可能让三线城市的正常订单也被标红。
- 用窗口函数最干净：
AVG(amount) OVER (PARTITION BY region)，但注意PARTITION BY region遇到region IS NULL会单独成一组，得提前处理或显式排除 - 如果用子查询关联，确保关联键完全匹配（比如
region = region且两边都非 NULL），否则产生笛卡尔积或漏组 - 某组只有 1 行时，
STDDEV_POP()返回 0，导致ABS(x - avg) / 0报错division by zero，得加CASE WHEN COUNT(*) = 1 THEN FALSE ELSE ... END
性能陷阱：大表跑标准差容易慢，先抽样再验证
千万级表上直接扫全量算 STDDEV_POP()，可能锁表几十秒。不是所有离群都需要 100% 精确，先快速定位可疑区间，再深查更实际。
- 用
TABLESAMPLE SYSTEM (1)（PostgreSQL）或LIMIT+OFFSET随机采样 5–10 万行，足够估计 σ 和分布形态 - 避免在
WHERE条件里嵌套多层子查询算统计量，MySQL 5.7 常因此退化成 N² 复杂度 - 如果字段有索引但类型是
TEXT或JSON，强制转成数值会失索引，CAST(content AS DECIMAL)前先WHERE content ~ '^[0-9.]+$'过滤格式
真正难的不是算出一个数字，而是确认这个“离群”背后是脏数据、作弊行为，还是新业务模式——统计结果只是起点，得留好原始 ID 和上下文字段，方便下钻。
