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从起点就被污染
标准差只是工具，不是规则。它依赖正态假设，而真实业务数据很少服从正态分布——这点最容易被忽略。
