MySQL的AVG()本身不四舍五入，返回精确浮点值；看似取整是因客户端显示截断、源列为INT导致渲染简略，或后续误用ROUND(AVG(col))未指定小数位所致。
AVG结果看起来像四舍五入，其实未必是ROUND在起作用
MySQL 的 AVG() 本身不执行四舍五入；它返回的是精确浮点计算值（DOUBLE 类型），但显示时可能被客户端截断、或因源列类型隐式转换导致“看似取整”。比如 INT 列求平均，结果仍是 DOUBLE，但若你用命令行客户端查，小数位可能被省略显示——这不是计算逻辑问题，是输出格式干扰判断。
列定义为INT时AVG结果为什么像整数
当源列是 INT，AVG() 计算过程仍用浮点运算，但部分旧版 MySQL 或某些连接驱动（如某些 JDBC 配置）会把 DOUBLE 结果按整数格式渲染。更关键的是：如果该列参与了隐式类型转换链（例如被 CAST 或函数包裹后又参与其他计算），精度可能提前丢失。
-
SELECT AVG(score) FROM student;中score是INT→ 实际返回89.280000000000001这类值，但客户端只显示89.28或甚至89 - 真正“变整数”的常见原因是后续用了
ROUND(AVG(...))却漏写小数位参数，等价于ROUND(x, 0) - 检查方式：用
SELECT AVG(score), CAST(AVG(score) AS CHAR) FROM student;看原始字符串表示，避开显示层干扰
DECIMAL列定义如何影响AVG精度
DECIMAL(M,D) 定义直接影响 AVG() 的中间计算精度。例如 score DECIMAL(5,2) 表示最多5位总长、2位小数，那么 AVG() 内部会基于该精度做定点运算，结果天然保留两位小数（但不是四舍五入，而是按 DECIMAL 规则截断/进位）。
- 建表时用
DECIMAL(10,2)存分数，比用FLOAT或INT更可靠 —— 因为AVG()对DECIMAL列的返回类型也是DECIMAL，避免浮点误差累积 - 但注意：
AVG()对DECIMAL列的结果精度 = 原列精度 + 小数位扩展（MySQL 8.0+ 默认扩展 4 位小数），所以DECIMAL(10,2)的AVG可能返回DECIMAL(14,6)，并非自动“保留2位” - 若要强制两位，仍需显式
ROUND(AVG(col), 2)或CONVERT(AVG(col), DECIMAL(10,2))
为什么ROUND(AVG(col), 2)有时不生效
最常踩的坑是源列含非数字内容或隐式转换失败。比如字段定义为 VARCHAR，里面混着 '95'、'缺考'、'' —— 此时 AVG() 会把非数字转成 0，再算平均，ROUND 只是对这个已被污染的结果修修补补。
- 先确认数据干净：
SELECT score FROM table WHERE score REGEXP '^[0-9]+\.?[0-9]*$' = 0;找出非法值 - 对字符型数字列，必须显式转换：
ROUND(AVG(CAST(score AS DECIMAL(10,2))), 2)，不能依赖隐式转换 - SQL Server 等数据库要求
CAST(delay AS FLOAT)才能对整型列用ROUND(AVG(...), 2)，否则报错 —— MySQL 虽宽松，但跨库迁移时这类写法会失效
真正决定“是否四舍五入”和“保留几位”的，从来不是 AVG() 自身，而是你是否在它外面套了 ROUND()、源列是否为 DECIMAL、以及有没有非数字数据偷偷参与了计算。别只盯着函数名，先查数据类型和数据质量。
