AVG()仅适用于数值型字段，对TEXT、VARCHAR或日期类型直接调用会报错；NULL值自动忽略，但空字符串和“0”需显式处理；DISTINCT影响语义与性能；返回类型由输入列决定，精度需显式控制。
AVG() 只能作用于数值型字段，非数字列会报错
直接对 TEXT、VARCHAR 或日期类型字段调用 AVG() 会触发错误，比如 ERROR: function avg(text) does not exist（PostgreSQL）或类似提示。数据库不会自动转换类型，也不会静默跳过——它直接拒绝执行。
常见误用场景包括：
- 对存储数字的字符串字段（如
"123"）直接求平均，需先用CAST(col AS NUMERIC)或TO_NUMBER(col, '999999')（Oracle）显式转换 - 对含单位的字段（如
"120kg"）未清洗就计算，必须先用正则提取数字部分 - 误以为
AVG(created_at)能算“平均时间”，实际应转为时间戳再处理，例如AVG(EXTRACT(EPOCH FROM created_at))
NULL 值被自动忽略，但空字符串 '' 和 '0' 不是 NULL
AVG() 确实跳过 NULL，但它不处理空字符串、空白符、或字符串 "0"。这些值若未被提前过滤或转换，可能参与计算并扭曲结果。
例如：字段 price 类型为 VARCHAR，内容含 "", "45", "60", "0", NULL —— 直接 AVG(price) 会失败（类型不匹配），而 AVG(CAST(NULLIF(price, '') AS NUMERIC)) 才能安全排除空字符串并跳过 NULL。
关键点：
-
NULLIF(col, '')把空字符串转成NULL，再由AVG()自动忽略 -
COALESCE(col, 0)是反模式：它把NULL补成0，人为拉低平均值 - 检查数据质量比硬写
COALESCE更可靠，可用SELECT COUNT(*), COUNT(col), COUNT(NULLIF(col, '')) FROM t快速对比
AVG(DISTINCT col) 和 AVG(col) 的语义差异容易被忽略
AVG(DISTINCT col) 先去重再平均，不是“去重后的平均值”这种模糊理解——它是数学意义上的唯一值集合均值。当字段存在大量重复时，两者结果可能差很多。
一款AI工具，主要用于运行或监督单遍 Codex 实现，包含预检门控、分步计划执行及严格的 QA 缺陷闭环。适用于执行已批准的售前...，适合需要提升相关任务效率的用户。
典型误判场景：
- 统计用户平均订单金额，误用
AVG(DISTINCT order_amount)，实际想算的是“每个用户的平均订单额”，应先GROUP BY user_id再AVG(order_amount) - 误认为
DISTINCT能解决数据重复污染，其实它掩盖了聚合粒度错误；真正该做的是确认业务口径：是“所有订单金额的平均值”，还是“每位客户订单金额的平均值的平均值”？ -
DISTINCT在大数据量下显著拖慢查询，因需排序或哈希去重；若仅需近似值，可考虑采样或预聚合表
浮点精度与返回类型取决于输入列，不是固定小数位
AVG() 返回类型由输入列决定：INT 列返回 NUMERIC 或 DOUBLE PRECISION（各数据库略有不同），但绝不会自动四舍五入到 4 位小数——那是客户端或某些 GUI 工具的显示行为，不是 SQL 标准。
需要可控精度时，必须显式处理：
- PostgreSQL / Redshift：
ROUND(AVG(col), 2) - MySQL：
ROUND(AVG(col), 2)或FORMAT(AVG(col), 2)（后者返回字符串） - SQL Server：
CAST(AVG(col) AS DECIMAL(10,2)) - 注意：
ROUND()对AVG()结果四舍五入，不是对原始值；若原始值有精度损失（如FLOAT存储），先转DECIMAL更稳妥
最常被绕开的问题是：没确认字段是否真为数值类型，也没验证 NULL 和空值的实际分布。跑出一个数字不等于结果可信——得先看 COUNT(col) 和 COUNT(*) 是否接近，再查 MIN()/MAX() 是否在合理区间。
