SQL中VAR/STDEV（SQL Server）或VARIANCE/STDDEV（PostgreSQL/Oracle/MySQL 8.0+）默认均为样本算法（分母n−1），非总体离散度；跨库须显式用VAR_SAMP/STDDEV_SAMP或VAR_POP/STDDEV_POP，且需处理NULL、单值组及数值类型校验。
直接用 VAR 和 STDEV（SQL Server）或 VARIANCE 和 STDDEV（PostgreSQL/Oracle/MySQL 8.0+）就能算，但默认全是样本算法（分母 n−1），不是你直觉里的“整体离散度”——这点不确认清楚，结果可能偏高 20% 以上。
GROUP BY 后直接聚合：选对函数名和语义
不同数据库函数名不统一，写错就报错或算错：
- SQL Server 必须用
VAR（样本方差）、VARP（总体方差）、STDEV（样本标准差）、STDEVP（总体标准差）；它不认STDDEV或VARIANCE - PostgreSQL / Oracle / MySQL 8.0+ 支持
VAR_SAMP/STDDEV_SAMP（样本）和VAR_POP/STDDEV_POP（总体）；VARIANCE和STDDEV是前者的别名，但 MySQL 5.7 不支持这两个简写 - 别图省事写
STDDEV(col)跨库迁移——明确写STDDEV_SAMP或STDDEV_POP才安全
NULL 和单值组会让结果变成 NULL，不是计算失败
VAR_SAMP 和 STDDEV_SAMP 要求每组至少 2 个非 NULL 值，否则返回 NULL（数学上除零非法）；VAR_POP/STDDEV_POP 在单值时返回 0。这不是 bug，是设计：
- 先查
COUNT(col)和COUNT(*)对比，确认缺失比例是否合理 - 若业务允许填充，用
COALESCE(STDDEV_SAMP(col), 0)统一补 0，但得清楚这掩盖了样本量不足的问题 - 过滤掉无效组更稳妥：
HAVING COUNT(col) > 1，避免下游解析NULL出错 - 显式排除空值：
WHERE col IS NOT NULL，否则整组全 NULL 时所有变体都返回NULL
字段不是数值类型？报错前先验证
STDDEV 类函数只接受数值类型，但错误常不直观：
- 报错
Operand data type varchar is invalid（SQL Server）或function stddev(text) does not exist（PostgreSQL），大概率是字段里混了空字符串、"N/A"、"123kg"或不可见字符 - 验证真实类型：
SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'col_name' - 临时转换（慎用）：
STDDEV(CAST(col AS NUMERIC))或STDDEV(col::NUMERIC)，但会把非法字符串转成NULL，进一步影响分母 - 真正要清理数据：
WHERE col ~ '^[0-9.+-eE]+$'（PostgreSQL 正则）或用TRY_CAST（SQL Server 2022+）
窗口函数里算分组内标准差：别加 ORDER BY
想保留原行数、每行都带本组标准差，用 OVER (PARTITION BY group_col)，但常见误用是加了 ORDER BY：
- 加
ORDER BY time_col会让STDDEV_SAMP(col) OVER (PARTITION BY dept ORDER BY time_col)变成“从第一行累加到当前行”的滚动标准差，不是你要的“整个部门的离散度” - 要真正的分组统计，只写
OVER (PARTITION BY dept)，不带ORDER BY - 单行分区时
STDDEV_SAMP仍返回NULL，需手动兜底：CASE WHEN COUNT(*) OVER (PARTITION BY dept) = 1 THEN 0 ELSE STDDEV_SAMP(col) OVER (PARTITION BY dept) END - 窗口函数自动忽略当前分区内的
NULL，但不会跳过整行输出——和聚合函数行为一致，只是粒度更细
最易被绕过的点：业务到底要“描述这群数据本身”（用 _POP 版本），还是“用这群数据估计更大总体”（用 _SAMP 版本）。小分组下两者差异显著，但 SQL 不会提醒你选错了。
