AVG函数天然忽略NULL值，直接使用AVG(col)即可正确计算非NULL值的平均数；误用COALESCE或WHERE过滤反而引入偏差，仅在业务明确要求“缺失即为0”时才需SUM(COALESCE(col,0))/COUNT(*)。

AVG函数本身已经忽略NULL值，不需要额外处理

SQL标准中的AVG()函数天然跳过NULL值计算——它只对非NULL数值求平均，分母是该列中非NULL的行数。很多人误以为需要COALESCE或WHERE过滤才能“正确”算平均，其实反而会引入偏差。

常见错误现象：
• 用AVG(COALESCE(col, 0))把NULL当0参与计算，拉低均值
• 写WHERE col IS NOT NULL再套AVG()，逻辑冗余且掩盖了原始数据分布

• AVG(col) 是最直接、语义最清晰的方式
• 若想确认是否真有NULL被跳过，可并行查COUNT(col)（只计非NULL）和COUNT(*)（全行数）作对比
• 所有主流数据库（PostgreSQL、MySQL 5.7+、SQL Server、SQLite、Oracle）行为一致

需要保留NULL参与计数时，必须手动重构计算逻辑

极少数场景下，业务要求“把缺失值视为0参与平均”，这已不属于统计意义上的均值，而是定制聚合。此时不能依赖AVG()，必须显式控制分子分母。

使用场景：
• 计算“人均应发奖金”（未发放记为0，而非无记录）
• 某些报表口径强制补零后平均

• 分子：用SUM(COALESCE(col, 0))
• 分母：用COUNT(*)（不是COUNT(col)）
• 完整表达式：SUM(COALESCE(col, 0)) * 1.0 / COUNT(*)（乘1.0防整数截断）
• 注意：此结果与AVG(COALESCE(col, 0))在MySQL/PostgreSQL中等价，但语义更透明；而SQL Server中AVG对COALESCE结果仍按非NULL计数，行为不一致，建议统一用SUM/COUNT(*)写法

GROUP BY中混合NULL与非NULL值时，AVG行为完全可靠

当按某列分组且该列含NULL时，标准SQL将所有NULL归为同一组（如PostgreSQL、SQL Server），AVG()在该组内仍只计算非NULL值。这是确定性行为，无需干预。

容易踩的坑：
• 误以为NULL组的AVG()会报错或返回NULL（实际返回该组内非NULL值的平均数，若组内全NULL才返回NULL）
• 在MySQL旧版本（sql_mode含STRICT_TRANS_TABLES）下，空组可能触发警告，但不影响结果

• 验证方式：SELECT grp_col, COUNT(*), COUNT(val_col), AVG(val_col) FROM t GROUP BY grp_col;
• 若需排除全NULL组，加HAVING COUNT(val_col) > 0
• 若需把NULL组单独标记，可用CASE WHEN grp_col IS NULL THEN 'unknown' ELSE grp_col END重映射

浮点精度与类型隐式转换影响结果可信度

AVG()返回类型由输入列决定：整数列返回DECIMAL或FLOAT，可能导致意外舍入。例如AVG(INT)在MySQL中默认返回带4位小数的DECIMAL，而PostgreSQL返回NUMERIC并保留高精度。

性能/兼容性影响：
• 跨数据库迁移时，相同数据可能因精度策略不同产生微小差异
• 大量数据下，AVG()比SUM()/COUNT()略快（优化器通常合并扫描）

• 显式控制精度：用ROUND(AVG(col), 2)或CAST(AVG(col) AS DECIMAL(10,2))
• 避免隐式转换：不要对字符串字段（如'123'）直接AVG()，先CAST(col AS NUMERIC)
• 注意NULL与0语义差异——前者是“未知”，后者是“已知为零”，混用会破坏分析前提

真正容易被忽略的是业务语义层：AVG跳过NULL是正确的，但“该列为什么有NULL”才是关键。是数据采集失败？还是业务上确实存在“不适用”情形？计算前先厘清NULL的来源，比纠结函数写法重要得多。