标准差这个统计量，在很多数据分析场景下都被视为“识别异常值的利器”。但说实话，不少人在 SQL 里一上来就用 STDEV()，然后期待它直接标出哪行数据有问题。这其实是个常见的认知偏差——函数本身只返回一个总体标量值，直接依赖它定位异常行，是行不通的。
STDEV 返回的只是单个数值，不是每行的偏离度
很多人误以为 STDEV(column) 会为每一行输出一个“该行距离均值的标准差倍数”。实际并不是这样——它在聚合上下文中运行，结果是一个统计值。比如这样写：
SELECT STDEV(sales_amount) FROM orders;
只会返回一行一列，比如 1248.67。这个数字本身并不会告诉你哪笔订单有问题。
想要真正识别异常点，你需要的是三个要素：均值 + 标准差 + 每行与均值的绝对偏差是否超过给定阈值（比如 2×STDEV）。这才是能落地的判断逻辑。
用子查询或窗口函数补上逐行计算的能力
问题在于，STDEV 是聚合函数，标准 SQL 中不支持直接用窗口函数来输出。SQL Server 倒是可以，比如这样：
- MySQL / PostgreSQL（无窗口 STDEV）：用子查询先算全局统计量，比如
ABS(sales_amount - (SELECT A VG(sales_amount) FROM orders)) > 2 * (SELECT STDEV(sales_amount) FROM orders) - SQL Server（推荐）：直接用窗口函数
ABS(sales_amount - A VG(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 < Q1 - 1.5*(Q3-Q1)或sales_amount > Q3 + 1.5*(Q3-Q1) - 还有一个容易被忽略的点：数据本身是否已排除脏数据（比如测试订单、退款订单）。如果没处理，
STDEV从起点就被污染了，结果可信度大打折扣。
总结一下：标准差只是个工具，不能自动套规则。它依赖于正态分布假设，但真实的业务数据很少满足这个假设。这一点，在实际应用中是最容易被忽略的。
