var和stdev是sql server专属函数，其他数据库不支持；postgresql用var_samp/var_pop，mysql用variance/stddev（8.0+），sqlite需扩展；各库默认按样本计算（分母n−1），总体需显式指定pop版本，且null值和非数值类型易致错误。
VAR 和 STDEV 是 SQL Server 专属函数，不能直接跨数据库复用；在 PostgreSQL、MySQL 或 SQLite 中写 VAR(score) 会报 function does not exist 错误。
确认数据库类型再写函数名
不同数据库对方差/标准差函数的命名和行为差异极大，硬套 VAR/STDEV 几乎必错：
- SQL Server：支持
VAR()（样本方差）、VARP()（总体方差）、STDEV()、STDEVP() - PostgreSQL：用
VAR_SAMP()/VAR_POP()，STDDEV_SAMP()/STDDEV_POP()；VAR()和STDDEV()是别名，但仅限于部分版本且不显式推荐 - MySQL 8.0+：支持
VARIANCE()（=VAR_SAMP()）、STDDEV()（=STDDEV_SAMP()），但不支持VAR()简写 - SQLite：无内置方差函数，需手算或加载扩展
实操前先跑：SELECT VERSION() 或查文档确认当前环境。别依赖“看起来像就对了”。
分组时 VAR 默认算样本方差，不是总体方差
VAR(score) 在 SQL Server 中默认按样本公式计算（分母为 n−1），结果比总体方差大——尤其当某组只有 3 条数据时，VAR() 比 VARP() 高约 50%。
选错会导致业务解读偏差：
- 若你分析的是全量数据（如“本季度所有门店销售额”），该用
VARP()或VAR_POP() - 若你做抽样推断（如“A/B 测试中随机抽取的用户行为”），才用
VAR()或VAR_SAMP() - 别用 Excel 的
VAR.S和VAR.P对照时只看数值，要同步确认口径是否一致
GROUP BY 后 NULL 和单值组会静默返回 NULL
VAR() 和 STDEV() 自动跳过 NULL，但不会警告。后果很实际：
- 整组全为
NULL→ 返回NULL - 组内只有一个非
NULL值 →STDEV()返回NULL（因n−1 = 0，除零非法），而STDEVP()返回0.0 - 下游应用若没处理
NULL，可能触发空指针或解析失败
稳妥做法：
- 显式过滤：
WHERE score IS NOT NULL，避免无效值干扰分母 - 防空返回：
COALESCE(STDEV(score), 0)（通用）或ISNULL(STDEV(score), 0)（SQL Server） - 检查基数：
COUNT(*)和COUNT(score)一起查，确认每组有效样本量是否合理
字段不是数值类型时会报 “Operand data type varchar is invalid”
这个错误不是因为字段名写错，而是列里混了非数字内容——哪怕只有一行是 "25kg"、"" 或不可见空格，STDEV() 就会炸。
排查步骤：
- 查真实类型：
SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'score' - 找脏数据：
SELECT score FROM table WHERE TRY_CAST(score AS FLOAT) IS NULL AND score IS NOT NULL（SQL Server） - 临时清洗：
STDEV(TRY_CAST(score AS FLOAT))，但注意TRY_CAST失败返回NULL，仍需结合前面的WHERE或COALESCE
最易被忽略的点：方差/标准差本身不报错，但一旦涉及隐式转换失败（比如字符串转数字），整个聚合就会中断——它不像 AVG() 那样宽容。
