AVG函数默认忽略NULL值，直接使用AVG(column_name)即可，无需WHERE column IS NOT NULL冗余过滤；其计算基于非空值个数与总和，如[100,200,NULL,300,NULL]结果为200.0。
AVG函数默认就忽略NULL值，不需要额外WHERE过滤
直接用 AVG(column_name) 就行——它天然跳过 NULL，只对非空数值求平均。很多人加 WHERE column_name IS NOT NULL 纯属冗余，还可能误伤业务逻辑。
比如表 sales 里 amount 有 5 行：100, 200, NULL, 300, NULL，AVG(amount) 结果是 200.0（(100+200+300)/3），不是 (100+200+0+300+0)/5。
什么时候才需要WHERE配合AVG？
只有当你想排除特定业务意义上的“无效值”，而这些值恰好不是 NULL 时，才用 WHERE。比如：
-
amount = 0表示退单，你不想计入平均销售额 -
status = 'cancelled'的记录要整体剔除 - 数值列混入了占位符如
-999或999999，需先过滤
这时写法是：SELECT AVG(amount) FROM sales WHERE amount > 0 AND amount IS NOT NULL —— 注意：仍建议显式写 IS NOT NULL，因为 > 0 虽能间接过滤 NULL，但语义不清晰，且在某些数据库（如 PostgreSQL）中，NULL > 0 返回 UNKNOWN，整行被排除，行为虽一致但可读性差。
GROUP BY + AVG 时 NULL 的表现和陷阱
分组后某组全为 NULL，AVG() 返回 NULL，不是 0 或报错。这容易导致前端展示为空或计算中断。
如果业务要求“全空组显示 0”，得用 COALESCE(AVG(column), 0)；若想彻底跳过该组，就得靠 HAVING COUNT(column) > 0 —— 因为 COUNT(column) 只统计非空，而 COUNT(*) 统计所有行。
错误写法：HAVING AVG(column) IS NOT NULL —— 这不能过滤掉全 NULL 的组，因为 AVG() 在该组返回 NULL，HAVING 条件不成立，但该组依然出现在结果中（只是 AVG 列为 NULL）。
性能与索引影响：WHERE 是否加速 AVG？
加 WHERE column IS NOT NULL 通常不会提升 AVG() 性能，因为 AVG 本身不扫描 NULL。但如果 WHERE 还包含其他高选择性条件（如 date > '2024-01-01'），那整个查询受益的是过滤后的数据量变小，而非 AVG 函数本身。
真正影响性能的是：该列是否有索引、是否允许 NULL、以及数据库是否支持索引覆盖（即仅从索引拿到所有需要的非空值，避免回表）。例如 MySQL 中，如果 amount 有单列索引且定义为 NOT NULL，AVG(amount) 可能走索引快速聚合；但如果允许 NULL，优化器可能放弃索引，改用全表扫描。
所以重点不在“要不要加 WHERE”，而在“列定义是否合理”和“索引是否匹配查询模式”。
