sql中variance和stddev默认按样本计算（除以n-1），postgresql、oracle、snowflake均如此；mysql的variance()等价var_samp()，stddev()等价stddev_samp()；sql server需显式用stdev()或stdevp()。
SQL里VARIANCE和STDDEV默认算的是总体还是样本？
绝大多数数据库（PostgreSQL、Oracle、Snowflake）中，VARIANCE和STDDEV默认按**样本**计算（即除以 n-1），对应统计学中的「样本方差」s² 和「样本标准差」s。MySQL 是个例外：它的 VARIANCE() 函数等价于 VAR_SAMP()，但 STDDEV() 默认是 STDDEV_SAMP()；而 SQL Server 完全不支持无前缀的 STDDEV，必须显式写 STDEV()（样本）或 STDEVP()（总体）。
容易踩的坑：
- 用
STDDEV(col)和STDDEV_POP(col)在同一数据上结果不同——前者小，后者大，别混用后还觉得是精度问题 - PostgreSQL 中
VAR_POP()和VARIANCE()不等价，后者 =VAR_SAMP() - 如果业务要求「总体标准差」（比如已知全量用户、非抽样），必须显式调用
VAR_POP()/STDDEV_POP()
窗口函数里怎么对分组内数据算标准差？
直接在 OVER 子句中套用 STDDEV_SAMP() 或 STDDEV_POP() 即可，关键是要把 PARTITION BY 指向你要的分组维度。例如按部门算员工薪资的标准差：
SELECT dept, name, salary, STDDEV_SAMP(salary) OVER (PARTITION BY dept) AS dept_salary_stddev FROM employees;
注意点：
-
STDDEV_SAMP()窗口函数要求分区至少有 2 行数据，否则返回NULL（单行无法算样本标准差） - 若想兼容单行场景并强制返回 0，得加
CASE WHEN COUNT(*) OVER (PARTITION BY dept) = 1 THEN 0 ELSE STDDEV_SAMP(salary) OVER (PARTITION BY dept) END - 排序（
ORDER BY）在标准差窗口中通常不需要——方差是无序聚合，加了反而可能触发范围帧（range frame），导致逻辑错误
为什么STDDEV窗口结果和先GROUP BY再JOIN不一致？
本质是空值（NULL）处理与聚合粒度差异。窗口函数会**自动忽略当前行的 NULL 值参与计算**，但保留该行输出；而 GROUP BY + JOIN 方案中，若 JOIN 条件没对齐空值，或分组时 NULL 被单独成组，就容易错位。
更隐蔽的问题是重复行：窗口函数逐行计算，每行都得到完整分组的 STDDEV；但若你用子查询 GROUP BY 得到一个汇总表，再 LEFT JOIN，却忘了 ON 条件覆盖所有分组键（比如漏了 WHERE 过滤后的 NULL 分组），就会出现某几行 STDDEV 为 NULL。
实操建议：
- 调试时先用
COUNT(*) OVER (PARTITION BY dept)和COUNT(salary) OVER (PARTITION BY dept)对比，确认非空值数量是否符合预期 - 避免用
GROUP BY+JOIN模拟窗口逻辑，除非明确需要物化中间分组结果 - 在 PostgreSQL 中可直接用
SELECT DISTINCT ON (dept) ...配合窗口，比手写JOIN更稳
ClickHouse / BigQuery / SQLite 怎么办？
各引擎语法差异明显，不能无脑移植：
- ClickHouse 没有
STDDEV_SAMP，只有stddevPop()（总体）和stddevSamp()（样本），且函数名全小写、带括号——写成STDDEV_SAMP()直接报错 - BigQuery 用
STDDEV()表示样本标准差，STDDEV_POP()表示总体，但窗口中必须加OVER()，且不支持ORDER BY（会报错 “Analytic function cannot have ORDER BY without window frame”） - SQLite 完全不支持窗口版
STDDEV，只能先GROUP BY算出分组值，再用程序层或 CTE 关联——没有捷径
跨平台最保险的做法：统一用 VAR_SAMP() + SQRT() 手动开方算标准差，因为 VAR_SAMP 支持度更高，且语义明确。
