MySQL和PostgreSQL中STDDEV()均默认计算样本标准差（除以n−1），对应STDDEV_SAMP()；需总体标准差时须显式使用STDDEV_POP()（除以n），否则小样本下结果存在偏差。
STDDEV 函数在 MySQL 和 PostgreSQL 中的行为差异
MySQL 的 STDDEV() 默认计算样本标准差（即除以 n−1），而 PostgreSQL 的 STDDEV() 也是样本标准差，但它的同义函数 STDDEV_SAMP() 更明确；如果你需要总体标准差（除以 n），得改用 STDDEV_POP()。不注意这点，同一组数据在两个库中跑出的数值可能差一点，尤其在小样本（比如 n ）时更明显。
常见错误现象：SELECT STDDEV(amount) FROM orders; 在 MySQL 和 PG 都能执行，但若你心里默认要的是“全体客户平均波动”，实际算出来却是“从这批订单抽样估计的波动”，结果会偏大。
- 业务场景如监控「每日销售额的稳定性」，通常用样本标准差即可；但做历史全量归档分析（比如「过去五年所有订单金额的离散程度」），应优先考虑
STDDEV_POP() - MySQL 8.0+ 和 PG 都支持
STDDEV_SAMP()和STDDEV_POP()，建议显式写出，避免歧义 - NULL 值会被自动忽略——这点和
AVG()一致，但如果你的业务要求把缺失值当作 0 处理，得先用COALESCE(amount, 0)
STDDEV 能不能直接用在 GROUP BY 或窗口函数里？
可以，但要注意聚合层级和 NULL 传播行为。比如按月份统计销售额标准差，STDDEV() 会为每个分组单独计算，这没问题；但若混用窗口函数，写成 STDDEV(amount) OVER (PARTITION BY region)，它算的是每个区域内部的样本标准差，不是全局的。
容易踩的坑：STDDEV() 是聚合函数，不能和非聚合字段混选而不加 GROUP BY——MySQL 5.7 严格模式下会报错 ERROR 1140: In aggregated query without GROUP BY，PG 则直接拒绝。
- 正确写法示例：
SELECT month, STDDEV(sales) FROM revenue GROUP BY month; - 窗口用法示例（PG/MySQL 8.0+）：
SELECT region, sales, STDDEV(sales) OVER (PARTITION BY region) AS region_std - 如果某个月份只有 1 条记录，
STDDEV()返回NULL（因 n−1=0 无法除），而不是 0——这是数学定义决定的，不是 bug
NULL、空集或单值输入导致 STDDEV 返回 NULL 怎么办？
STDDEV() 对空结果集或仅含一个非 NULL 值的集合，统一返回 NULL。这不是异常，而是 SQL 标准行为：标准差在样本数小于 2 时无定义。但业务报表常要求显示 “0” 或 “—” 来表示“无波动”，这时不能靠 IFNULL() 简单兜底，得先判断有效值个数。
实操建议：用 COUNT() 配合 CASE 控制输出。
SELECT
COALESCE(
CASE WHEN COUNT(amount) > 1 THEN STDDEV(amount) END,
0
) AS std_amount
FROM transactions;
- 上面写法把单值/空集情况强制转为 0，适合监控看板类场景；但如果是审计用途，保留
NULL反而更严谨 - 不要用
IFNULL(STDDEV(amount), 0)——因为STDDEV()本身在无效输入时就返回NULL，这个写法看似省事，实则掩盖了数据稀疏问题 - 如果字段本身有大量 NULL（比如
discount_rate仅部分订单有），STDDEV()已自动过滤，无需额外WHERE discount_rate IS NOT NULL
STDDEV() 显著膨胀。真要衡量业务波动，不妨搭配 PERCENTILE_CONT(0.5) 看中位数绝对偏差，或者先用 WHERE amount BETWEEN ... AND ... 剔除明显脏数据——函数只是工具，解释权永远在人手里。 
