AVG()仅适用于数值列且自动忽略NULL，对非数字类型或含非法字符串的数据会报错；使用时需确认列类型、清理异常值、正确配合GROUP BY和HAVING，并注意精度控制与边界情况。
AVG() 函数只能作用于数值列，NULL 值自动被忽略
直接对非数字类型（如 TEXT、VARCHAR）用 AVG() 会报错，比如 MySQL 报 Invalid use of group function 或隐式转换失败；PostgreSQL 更严格，直接拒绝。另外，哪怕列定义是数字类型，如果实际存了空字符串或 'N/A' 这类字符串，也会在转换时出错或产生意外结果。
实操建议：
- 先确认目标列类型：
DESCRIBE table_name;（MySQL）或\d table_name（PostgreSQL） - 检查是否有非数字数据：
SELECT column_name FROM table_name WHERE column_name NOT REGEXP '^-?[0-9]+\.?[0-9]*$';（MySQL 8.0+）或用TRY_CAST（SQL Server）、TO_NUMBER()（PostgreSQL）做安全转换 - 若列含 NULL，无需额外处理——
AVG()默认跳过它们，但要注意：全为 NULL 时返回NULL，不是 0
GROUP BY 后用 AVG() 是常见需求，但别漏掉非聚合字段
当 SELECT 中同时出现 AVG() 和普通字段（如 category），必须用 GROUP BY 显式声明这些字段，否则多数数据库（MySQL 5.7+ 严格模式、PostgreSQL、SQL Server）会报错：column must appear in the GROUP BY clause or be used in an aggregate function。
示例场景：查每类商品的平均售价
SELECT category, AVG(price) AS avg_price FROM products GROUP BY category;
容易踩的坑：
- 写成
SELECT category, name, AVG(price)却只GROUP BY category→ 报错，因为name没聚合也没分组 - 想“取每个分组里价格平均值，再附带一个样例名称”，得用子查询或窗口函数，不能靠 GROUP BY 混搭
- MySQL 5.7 以前允许这种写法（
sql_mode不含ONLY_FULL_GROUP_BY），但结果不可靠——name可能来自任意一行
AVG() 结果精度受字段类型和数据库影响，别默认信任小数位数
AVG() 返回值类型不总是和原列一致。例如 MySQL 对 INT 列算平均值，默认返回 DECIMAL(10,2)；而 PostgreSQL 的 AVG(INT) 返回 NUMERIC，精度可能远高于预期（比如 15 位小数），前端展示时容易溢出或显示冗长。
控制精度的常用方式：
- 用
ROUND(AVG(price), 2)截断到两位小数（所有主流数据库都支持） - PostgreSQL 可显式转类型：
AVG(price)::DECIMAL(10,2) - 注意：
ROUND()是四舍五入，不是截断；若需截断，MySQL 用TRUNCATE(AVG(price), 2)，PostgreSQL 用TRUNC(AVG(price), 2) - 避免在 WHERE 中对
AVG()做条件——它不能出现在 WHERE 子句，得用HAVING
WHERE 和 HAVING 都能过滤，但时机和对象完全不同
WHERE 在分组前过滤行，HAVING 在分组后过滤分组。想查“平均售价超 100 的品类”，必须用 HAVING AVG(price) > 100；若写成 WHERE AVG(price) > 100，数据库直接报语法错误。
典型误用场景：
- 查销量大于 50 的订单的平均金额 → 先
WHERE order_qty > 50，再AVG(amount) - 查平均金额大于 500 的客户 → 必须
GROUP BY customer_id+HAVING AVG(amount) > 500 - 混合使用时，
WHERE一定在GROUP BY前，HAVING一定在GROUP BY后
AVG 的边界情况比看起来多：空表、全 NULL、整型溢出、精度丢失、隐式转换失败——这些不会总抛异常，有时只静默返回错误值。动手前，先 SELECT COUNT(*), COUNT(column), MIN(column), MAX(column) 看一眼数据分布更稳妥。
