STDDEV本身不能直接标记离群值，必须结合均值与阈值逻辑（如均值±3倍标准差）构造动态上下界，再用CASE WHEN或WHERE过滤；推荐用窗口函数（如AVG() OVER、STDDEV_SAMP() OVER）实现分组内Z-score计算，并用NULLIF防除零，IQR法更鲁棒。
STDDEV 本身不能直接标记离群值，必须配合均值和阈值逻辑
直接写 STDDEV(amount) 只会返回一个数字，没法告诉你哪几行是离群值。要识别离群值，得用「均值 ± k 倍标准差」构造动态上下界，再用 CASE WHEN 或 WHERE 过滤。这个过程本质是 Z-score 的 SQL 模拟，不是调个函数就完事。
常见错误现象：
• 把 SELECT *, STDDEV(amount) OVER() 当成每行都带自己的标准差（错：它返回的是全表或分区的固定值）
• 忘记标准差对单点无效——若某组只有 1 行，STDDEV_SAMP() 返回 NULL，后续减法/比较直接失效
• 用 STDDEV() 却没配 AVG()，导致上下界失去中心参照
- 推荐写法（以 PostgreSQL / MySQL 8.0+ 为例）：
SELECT id, amount,
AVG(amount) OVER() AS mean_amt,
STDDEV_SAMP(amount) OVER() AS std_amt,
CASE
WHEN amount AVG(amount) OVER() + 3 * STDDEV_SAMP(amount) OVER() THEN 'high_outlier'
ELSE 'normal'
END AS flag
FROM orders;
注意：这里用 OVER() 是全表范围；若需按业务维度（如 per month），改用 OVER(PARTITION BY DATE_TRUNC('month', created_at))。
分组内离群值检测必须用窗口函数，别用 GROUP BY 后 JOIN
想查“每个品类里哪些商品价格异常”，不能先 GROUP BY category 算出各组 STDDEV_SAMP(price)，再 JOIN 回原表——容易因 NULL、重复键或空分组导致某几行丢失 std 值，且性能差。
正确姿势是直接上窗口函数，让每行自带所属分组的统计量：
SELECT id, category, price,
AVG(price) OVER (PARTITION BY category) AS cat_mean,
STDDEV_SAMP(price) OVER (PARTITION BY category) AS cat_std,
ABS(price - AVG(price) OVER (PARTITION BY category)) /
NULLIF(STDDEV_SAMP(price) OVER (PARTITION BY category), 0) AS z_score
FROM products
WHERE price IS NOT NULL;
关键点：
• NULLIF(..., 0) 防止某品类标准差为 0（所有价格相同）时除零报错
• WHERE price IS NOT NULL 提前过滤，避免窗口计算中混入 NULL 扰乱 STDDEV_SAMP
• 若某品类只有 1 个非空价格，STDDEV_SAMP 返回 NULL，整行 z_score 就是 NULL，自然被排除在后续条件外
用 IQR 替代 STDDEV 更鲁棒，尤其当数据偏态或含极端值
STDDEV 对离群值极度敏感——一个超大金额会把标准差拉高，导致其他本该算离群的点被“稀释”进正常范围。这时应优先考虑四分位距（IQR）法，它基于分位数，天然抗干扰。
各数据库支持度差异大：
• PostgreSQL / BigQuery / Snowflake：原生支持 PERCENTILE_CONT(0.25) 和 PERCENTILE_CONT(0.75)
• MySQL 8.0+：需用窗口函数模拟，或借助 JSON_TABLE + 排序技巧（较重）
• SQL Server：用 PERCENTILE_CONT（2012+）
PostgreSQL 示例（安全计算 IQR 上下界）：
WITH q AS (
SELECT category, price,
PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY price) OVER (PARTITION BY category) AS q1,
PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY price) OVER (PARTITION BY category) AS q3
FROM products
WHERE price IS NOT NULL
),
iqr_bounds AS (
SELECT *, (q3 - q1) * 1.5 AS iqr_range
FROM q
)
SELECT *,
CASE
WHEN price q3 + iqr_range THEN 'high_outlier'
END AS iqr_flag
FROM iqr_bounds;
注意：PERCENTILE_CONT 要求排序字段非 NULL，所以前置 WHERE price IS NOT NULL 不可省；另外，q1 和 q3 在单值分组中仍能返回有效值（不像 STDDEV_SAMP 直接变 NULL），这点更稳定。
别忽略数据类型和 NULL 处理的连锁影响
看似简单的 STDDEV(price)，背后可能因字段类型或缺失值引发静默失败：
- 字段是
VARCHAR但存了数字字符串（如'1200'）？多数数据库会隐式转，但一旦混入'N/A'或空格，STDDEV直接报错：invalid input syntax for type numeric - 字段是
DECIMAL但用了浮点聚合？MySQL 中STDDEV默认返回DOUBLE，金额类字段易丢精度，建议显式CAST(price AS DECIMAL(12,2)) - 整列 30% 是
NULL？STDDEV自动跳过，但下游业务可能误以为“波动小”，其实只是有效样本少——务必同步查COUNT(*)和COUNT(price)
最易被忽略的一点：STDDEV_POP 和 STDDEV_SAMP 在单行分组行为不一致。STDDEV_POP(x) 在单行时返回 0.0，而 STDDEV_SAMP(x) 返回 NULL。如果你用 STDDEV_POP 写离群判断，单行组会被错误归为“无波动”，掩盖样本量不足问题。生产环境建议统一用 STDDEV_SAMP，并主动加 HAVING COUNT(*) > 1 或窗口内 COUNT(*) OVER (...) > 1 控制入口。
