STDEV函数仅返回整体样本标准差这一标量值，无法直接定位异常行；须结合均值与每行偏差（如ABS(x−AVG)＞2×STDEV）并通过子查询或窗口函数实现逐行判断。

STDEV 函数不能直接用于识别异常点，它只返回一个标量值（整体样本标准差），必须配合其他逻辑才能定位异常行。

STDEV 返回的是单个数值，不是每行的偏离度

很多人误以为 STDEV(column) 会为每一行输出一个“该行距离均值的标准差倍数”，实际它在聚合上下文中运行，结果是整个列的一个统计值。例如：

SELECT STDEV(sales_amount) FROM orders;

只会返回一行一列，比如 1248.67 —— 这个数字本身不告诉你哪笔订单异常。

要识别异常点，你需要：均值 + 标准差 + 每行与均值的绝对偏差是否超过阈值（如 2×STDEV）。

用子查询或窗口函数补足缺失的逐行计算能力

SQL 标准中 STDEV 是聚合函数，不支持直接窗口化（SQL Server 支持 STDEV OVER()，但 MySQL 和旧版 PostgreSQL 不支持）。稳妥做法是用子查询先算出全局统计量：

• MySQL / PostgreSQL（无窗口 STDEV）：(ABS(sales_amount - (SELECT AVG(sales_amount) FROM orders)) > 2 * (SELECT STDEV(sales_amount) FROM orders))
• SQL Server（推荐）：ABS(sales_amount - AVG(sales_amount) OVER()) > 2 * STDEV(sales_amount) OVER()
• 注意：PostgreSQL 中对应函数是 STDDEV_SAMP()，不是 STDEV；MySQL 8.0+ 才有 STDDEV_SAMP()，5.7 只有 STDDEV()（等价于 STDDEV_SAMP()）

STDEV vs STDEVP：选错会导致阈值偏移

业务数据通常是样本（你只拿到部分订单，不是全部历史），应使用样本标准差 STDEV（SQL Server）或 STDDEV_SAMP()（PostgreSQL）。若误用总体标准差 STDEVP 或 STDDEV_POP()，计算结果偏小，导致异常判定过严——本来正常的中高销售额也会被标红。

验证方法：对 5 行数据 [100, 120, 110, 130, 140]，STDDEV_SAMP ≈ 15.8，STDDEV_POP ≈ 14.1 —— 差 1.7，乘以 2 后就是 3.4 的判定边界差距。

真实业务中更需警惕“标准差失灵”的场景

当订单金额分布严重右偏（大量小额 + 少量大额）或含明显分群（如 B2B 和 B2C 订单混在一起），STDEV 会被极端值拉高，导致常规订单也落在 “均值±2σ” 外。此时直接过滤会漏判真异常、多判正常点。

实用对策：

• 先按业务维度分组再算标准差，例如：STDEV(sales_amount) OVER(PARTITION BY customer_type)
• 改用四分位距（IQR）：计算 PERCENTILE_CONT(0.25) 和 PERCENTILE_CONT(0.75)，异常定义为 sales_amount 或 <code>> Q3 + 1.5*(Q3-Q1)
• 确认数据已排除已知脏数据（如测试订单、退款订单），否则 STDEV 从起点就被污染

标准差只是工具，不是规则。它依赖正态假设，而真实业务数据很少服从正态分布——这点最容易被忽略。