AVG()与GROUP BY联用结果全为NULL的主因是某组工资字段全为NULL，AVG()直接返回NULL而非跳过；需检查字段类型、WHERE筛选、分组列合规性、地区数据标准化及异常值影响。
AVG() 和 GROUP BY 一起用时，为什么结果全是 NULL？
常见错误是 AVG() 遇到某地区所有工资字段为 NULL，直接返回 NULL，而不是跳过该组或报错。这容易让人误以为查询没生效。
- 确认工资字段类型是数值型（如
DECIMAL、INT），不是字符串——字符串型字段即使看起来像数字，AVG()也会静默转成0或报错，取决于数据库（MySQL 会尝试转换，PostgreSQL 直接报错） - 检查是否在
WHERE子句中误筛掉了全部记录，比如写成WHERE salary > 0 AND region = 'xxx'，而该地区恰好有大量0工资记录被排除 - 如果想忽略
NULL但保留空组，得配合COALESCE(AVG(salary), 0)；但要注意：这不是“把 NULL 当 0 算进平均值”，而是“平均完是 NULL 就显示 0”
GROUP BY 后 SELECT 列必须是分组键或聚合函数，否则报错
MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY，PostgreSQL 和 SQL Server 始终严格要求。一旦写成 SELECT region, name, AVG(salary)，name 不在 GROUP BY 里，必然报错。
- 正确写法只能是：
SELECT region, AVG(salary) FROM employees GROUP BY region - 如果还想看每个地区的最高工资，就加一个
MAX(salary)，不能混入非聚合的原始列 - 别依赖 MySQL 旧版本“自动取第一行”的行为——它不可靠，且迁移到其他数据库时立刻崩
地区字段含空格、大小写、拼写不一致，导致分组出多个“同一地区”
比如 'beijing'、'Beijing '、'BEIJING' 会被当成三个不同组，平均值各自计算，结果分散且失真。
- 先用
SELECT DISTINCT TRIM(UPPER(region)) FROM employees检查实际值分布 - 清洗时优先在
GROUP BY中标准化：GROUP BY TRIM(UPPER(region))，但注意这会影响索引使用，大数据量慎用 - 更稳妥的做法是在 ETL 或插入时统一清洗，而不是每次查询都
TRIM(UPPER()) - 中文地区名还要警惕全角/半角空格、不可见字符（如
U+3000），LENGTH(region)和CHAR_LENGTH(region)对比能暴露问题
AVG 计算的是算术平均，对异常值敏感，别把它当“典型工资”
一个地区若混入 CEO 和实习生数据，AVG() 可能远高于大多数人工资，但报表里看不出这点。
- 简单补救：加
COUNT(*)和MIN()/MAX()一起查，快速判断数据分布是否合理 - 想看中位数？标准 SQL 没内置函数，PostgreSQL 用
PERCENTILE_CONT(0.5)，MySQL 8.0+ 用窗口函数模拟，别硬套AVG() - 如果业务上“平均工资”实际指“去掉最高最低后的均值”，就得手写子查询过滤，
AVG()本身做不到
真正麻烦的不是语法写不对，而是拿到 AVG() 结果后没意识到它背后假设了数据均匀、无偏、可加——而现实里工资数据从来不是这样。
