avg函数默认包含零值会拉低平均值，应使用where column_name != 0过滤零值；null自动被忽略，无需额外处理；需结合业务语义判断0是否为有效数据。
AVG函数默认包含零值，直接用会拉低平均值
SQL 的 AVG() 函数对整列（含 0 和 NULL）做算术平均，而业务中“0”常表示“未发生”或“无效采集”，比如用户点击数为 0、传感器读数为 0（实际是设备离线）、订单金额为 0（测试单）。这时把 0 当有效数据参与计算，结果明显偏低。
用 WHERE 过滤零值是最简单可靠的方案
在聚合前剔除 0 值，让 AVG() 只作用于非零有效数据。注意：NULL 本身不会被 AVG() 计入，所以无需额外处理 NULL，但 0 必须显式排除。
- 写法：
SELECT AVG(column_name) FROM table_name WHERE column_name != 0 - 若字段可能为 NULL，且你只想要非零非空值，用
WHERE column_name > 0（适用于非负场景）或WHERE column_name IS NOT NULL AND column_name != 0 - 负值需保留时（如温度变化、损益值），必须用
!= 0或NOT IN (0)，避免误删负数
慎用 CASE WHEN + AVG 组合，容易误算分母
有人尝试 AVG(CASE WHEN column_name != 0 THEN column_name END)，这看似优雅，但要注意：CASE 表达式对 0 值返回 NULL，而 AVG() 自动跳过 NULL —— 所以结果和 WHERE 方案一致。但问题在于可读性差，且一旦写成 AVG(CASE WHEN ... THEN column_name ELSE 0 END)，就又把 0 拉回计算了。
更隐蔽的坑：如果混用 SUM 和 COUNT 手动算平均（如 SUM(col)/COUNT(*)），COUNT(*) 会统计所有行，包括 0 值行，导致分母偏大 —— 这比直接用 AVG() 更容易出错。
考虑业务语义：0 是缺失值还是真实值？
真正棘手的不是语法，而是判断“这个 0 到底该不该排除”。例如：
- 库存字段为 0 → 通常是真实状态，应保留
- API 响应耗时字段为 0 → 很可能是日志埋点失败，应排除
- 用户评分字段为 0 → 多数系统不支持 0 分，属于非法数据，应视为脏数据清洗掉
没有通用规则，得翻产品文档或问业务方。写 SQL 前花两分钟确认这点，比调半天查询结果更有价值。
