使用VARIANCE()/STDDEV()需区分样本与总体，否则偏差达5%–20%；NULL值默认被跳过但不警告；计算CV时需用NULLIF(ABS(AVG(x)),0)防浮点误差；标准差须结合均值与业务解读；命名应明确如price_stddev_pop；时间序列对比须统一用STDDEV_SAMP()。
直接用 VARIANCE() 或 STDDEV() 计算离散程度，必须先明确数据是样本还是总体——选错函数，结果偏差可达 5%–20%，尤其在小数据集（n
STDDEV() 和 STDDEV_POP() 到底该用哪个
这两个函数不是“差不多”，而是统计定义完全不同：
-
STDDEV()（或STDDEV_SAMP()）按样本标准差计算，分母是n−1，适用于抽样、日志切片、A/B 测试组等“只是总体一部分”的场景 -
STDDEV_POP()按总体标准差计算，分母是n，只适用于你确认已掌握全部数据，比如某天全量订单、全公司员工薪资表 - MySQL 5.7/8.0 中
STDDEV()等价于STDDEV_SAMP()；PostgreSQL 和 Oracle 两者都支持，但不写全容易混淆；SQL Server 对应的是STDEV()和STDEVP() - 误用后果：用
STDDEV_SAMP()分析全量数据，结果偏高；用STDDEV_POP()分析抽样，结果偏低——业务上可能把“稳定组”误判为“波动大”，或反之
VARIANCE() 和 STDDEV() 的关系与误用风险
VARIANCE() 是 STDDEV() 的平方，数学上等价，但业务解读极易出错：
- 别把
VARIANCE(salary)的输出标为「平均薪资波动」——方差单位是原单位的平方（如元²），无法直观理解；标准差才是和原始数值同量纲的离散度指标 - 比较不同字段（如订单金额 vs 用户停留时长）的离散程度时，必须用变异系数
STDDEV(x) / NULLIF(AVG(x), 0)，而不是直接比VARIANCE()值 - 某些引擎（如 Oracle）中
STDDEV()单行输入返回0，而STDDEV_SAMP()返回NULL，混用会导致 GROUP BY 后部分组结果为空，部分为 0，难以排查
GROUP BY 后计算标准差的三个关键检查点
分组后调 STDDEV_POP(price) 看各城市房价波动？先确认这三件事：
- 每组是否至少有 2 条有效记录？
STDDEV_SAMP()在单值组返回NULL，STDDEV_POP()返回0，但“0 波动”不等于“无风险”，需加HAVING COUNT(*) > 1过滤 - NULL 值是否已处理？
STDDEV()类函数默认跳过 NULL，但不会警告——若score字段有 15% 是 NULL，函数只基于 85% 数据计算，结果代表性存疑；建议先跑SELECT COUNT(*), COUNT(score) FROM exam_results查缺失率 - 均值是否接近零？算变异系数（CV）时，
AVG(x)可能为极小浮点数（如1e-15），NULLIF(AVG(x), 0)失效，推荐改用NULLIF(ABS(AVG(x)), 0)加一层防御
为什么不能只看标准差数值大小
标准差本身没意义，必须结合均值和业务语境读：
- 某类商品售价
STDDEV_POP(price) = 120，如果均值是200元，CV ≈ 0.6，说明价格差异极大；如果均值是5000元，CV ≈ 0.024，其实很集中 - 导出报表时，字段命名要准确：
price_stddev_pop比 “价格波动” 清晰，cv_price比 “离散率” 不易歧义 - 时间序列对比（如周环比波动）必须统一用
STDDEV_SAMP()，否则分母逻辑不一致，导致同比失真——这点常被忽略，直到报表上线后发现“上周波动突然变小”，其实是函数混用了
