avg()仅接受数值类型，对varchar、date等非数值类型在解析阶段即报错，不尝试隐式转换；必须用cast显式转换，注意精度、溢出、空格及性能问题。
因为 AVG() 只接受数值类型，遇到字符串、日期、NULL 或混合类型列时会直接报错或返回意外结果 —— 不是函数本身不工作，而是它根本“拒绝处理”非数值输入。
AVG() 对数据类型的硬性要求
AVG() 是强类型聚合函数，SQL Server（以及绝大多数标准 SQL 引擎）在解析阶段就会校验表达式的数据类型。如果传入的是 VARCHAR、NVARCHAR 或 DATE，哪怕内容全是数字（如 '100'、'2023-01-01'），也会报错：
Msg 8117, Level 16, State 1: Operand data type varchar is invalid for avg operator.
这不是警告，是编译期错误，查询根本不会执行。
- 它不尝试隐式转换 —— 即使
WHERE age = '25'能隐式转成功，AVG(age)中的age若定义为VARCHAR，仍会失败 - 它也不接受
BIT、XML、GEOMETRY等非算术类型，哪怕值只有 0/1 -
NULL值虽被自动忽略，但前提是该列本身是数值类型；若列是字符串且含NULL，先过不了类型检查这一关
什么时候必须用 CAST 显式转换？
常见于三类场景：用户输入存为字符串、日志表字段统一用 VARCHAR、遗留系统未规范建模。此时不能依赖隐式转换，必须主动包裹 CAST：
- 字符串数字列：用
CAST(price_str AS DECIMAL(10,2))，别用INT—— 小数会截断 - 带单位或符号的字符串：如
'¥129.99'或'+42'，需先用REPLACE清洗，再CAST，否则报错 - 日期列误求平均：比如对
order_date直接AVG(order_date)，必须先转成天数差（如DATEDIFF(day, '1970-01-01', order_date)），再AVG，最后反推日期 —— 否则语法不通
CAST 转换时最容易踩的坑
不是所有 CAST 都安全，尤其在聚合前：
- 精度丢失：用
CAST(x AS INT)再AVG，等于先砍掉小数再平均，和AVG(CAST(x AS DECIMAL))结果不同 - 溢出失败：字符串
'9999999999'转INT会报错，应改用BIGINT或DECIMAL(18,0) - 空格/不可见字符：
' 123 '或'123\t'无法直接CAST，必须TRIM或RTRIM(LTRIM()) - 性能陷阱：在大表上对整列做
CAST+AVG，相当于每行都触发类型转换，无法走索引，可能拖慢数倍
为什么不用 CONVERT？
功能上 CONVERT 和 CAST 在数值转换中基本等价，但 CAST 更可靠：
-
CONVERT的style参数对数值类型无效，纯属冗余 -
CONVERT在某些 SQL Server 版本中对非法字符串返回NULL而不报错（如CONVERT(INT, 'abc')），掩盖数据质量问题 -
CAST是 ANSI 标准，跨数据库兼容性更好；而CONVERT是 SQL Server 扩展，迁移到 PostgreSQL 或 MySQL 时得重写
真正关键的不是“能不能转”，而是“在哪转、怎么转、转完还准不准”。很多问题表面是 AVG() 报错，根子在建表时没约束类型，或 ETL 时放任字符串入库 —— 这些地方比写对一个 CAST 更值得花时间修正。
