AVG() 返回 NULL 时用 COALESCE(AVG(col), 0) 安全兜底；WHERE 在分组前过滤行，HAVING 在分组后过滤组；AVG 忽略 NULL 但计入 0，需排除 0 时用 AVG(NULLIF(col, 0))；大表 AVG 性能优化优先考虑覆盖索引或预计算。
AVG() 返回 NULL 而不是 0，怎么处理？
当 AVG() 的输入列全为 NULL，或查询结果为空行时，它直接返回 NULL，不是 0。业务代码里如果没判空，容易引发空指针或类型转换异常。
- 用
COALESCE(AVG(col), 0)显式兜底，这是最常用也最安全的做法 - 避免用
IFNULL(AVG(col), 0)—— 它在严格模式下可能因聚合前无数据而报错Invalid use of group function - 如果统计的是带条件的子集（比如「近 7 天订单金额」），记得先确认该时间段是否有记录，否则
COALESCE仍会返回NULL
WHERE 和 HAVING 都能过滤 AVG，该用哪个？
本质区别在于执行时机：WHERE 在分组前筛行，HAVING 在分组后筛组。想算「每个部门平均工资 > 8000 的部门」，必须用 HAVING；但「只统计在职员工」就得写在 WHERE 里。
-
WHERE salary > 0 AND status = 'active'→ 先剔除无效记录，再分组求平均，结果更准、性能更好 -
HAVING AVG(salary) > 8000→ 必须配合GROUP BY，否则语法错误 - 误把条件写反（比如把
status判断放进HAVING）会导致逻辑错误：MySQL 允许但语义失效，因为HAVING无法访问未聚合的单行字段
AVG 计算时自动忽略 NULL，但你可能不知道它也忽略 0
AVG() 只跳过 NULL 值，0 是有效数值，会被计入分母和分子。但业务上常把 0 当作“未填写”或“无效值”，这时直接用 AVG(col) 就会拉低均值。
- 若需排除 0，改用
AVG(NULLIF(col, 0))—— 把 0 转成NULL后再算平均 - 注意
NULLIF(col, 0)对负数、字符串都安全，但对浮点数要小心精度问题（比如0.0001不会被转成NULL） - 如果字段本身允许
NULL，又混着存了真实 0 和缺失值，得先统一清洗，不能只靠函数补救
大表上用 AVG 慢？别急着加索引
AVG() 是聚合函数，必须扫描所有参与计算的行，普通 B+Tree 索引对它加速有限。除非你只查某个固定条件下的平均值，且该条件能走索引快速定位数据子集。
- 加索引前先看执行计划：
EXPLAIN SELECT AVG(amount) FROM orders WHERE created_at > '2024-01-01'—— 如果type是range且rows显著减少，索引才有意义 - 覆盖索引（如
INDEX(created_at, amount)）能让 MySQL 仅从索引树取数，避免回表，对带WHERE的AVG有帮助 - 千万级表做全表
AVG，考虑用定时汇总表或物化视图（MySQL 8.0+ 可用CREATE TABLE …… AS SELECT预计算）
AVG 看似简单，但 NULL 处理、过滤时机、值有效性判断、性能边界这四点，任何一个没对齐业务语义，结果就不可信。特别是 NULL 和 0 的混用场景，线上出过太多“平均工资 3000 元”的诡异报表。
