为什么在SQL中运用AVG平均值函数时需注意整数除法问题？

AVG()对整数列求平均时默认按整数除法截断小数，导致结果失真；必须在计算前用CAST(列名 AS DECIMAL)或列名*1.0提升精度，而非依赖ROUND(AVG(),n)事后修正。

AVG() 返回整数结果时会截断小数，不是四舍五入

当列是 INT、TINYINT 等整数类型时，多数数据库（MySQL、SQL Server、PostgreSQL）的 AVG() 会先算总和再除以行数，而整数除法直接丢弃小数部分。比如 80, 90, 99 三值平均本应是 89.666...，但结果可能显示为 89。

这不是显示问题，而是计算过程就截断了——连 ROUND() 都救不回来，因为输入已经是整数。

• MySQL 默认行为：对整数列返回 DECIMAL 类型，但精度可能不足（如只保留 1 位小数）
• SQL Server 和旧版 PostgreSQL：直接返回整数，小数全丢
• Oracle：行为类似，取决于列定义和数据库版本

怎么让 AVG() 返回带小数的正确结果？

核心思路是：在除法发生前，把至少一个操作数变成浮点或高精度类型。最常用且兼容性好的写法是：

• 用 CAST(列名 AS DECIMAL(10,2)) —— 显式控制精度，推荐用于报表类场景
• 用 列名 * 1.0 或 列名 * 1.00 —— 简洁，但依赖隐式转换，不同数据库对小数位数处理略有差异
• 用 CONVERT(DECIMAL(10,2), 列名) —— SQL Server 特有，功能等价于 CAST

示例：SELECT AVG(CAST(amount AS DECIMAL(10,2))) FROM sales; 比 SELECT AVG(amount) FROM sales; 更可靠。

为什么不能只靠 ROUND(AVG(col), 2)？

因为 ROUND() 是对 AVG() 的输出做四舍五入，而如果 AVG() 内部已经按整数除法算出 89，那 ROUND(89, 2) 还是 89.00，无法还原丢失的小数。

常见误用场景：

• SELECT ROUND(AVG(score), 2) FROM students; —— score 是 INT，结果仍是整数再 round，没意义
• SELECT AVG(score) AS avg_score FROM students; —— 看似没问题，但导出到 Excel 或前端展示时发现全是整数

真正有效的写法必须干预除法环节本身，而不是事后修饰。

除 AVG() 外，所有涉及除法的地方都得警惕

不只是 AVG()，任何显式除法表达式，比如计算完成率：(success_count / total_count) * 100，只要两个字段都是整数，结果就是 0（当 success_count

安全写法统一原则：确保分子或分母至少一个是浮点数。

• 写成 (success_count * 1.0 / total_count) * 100
• 或更严谨：CAST(success_count AS DECIMAL(10,2)) / NULLIF(total_count, 0) * 100（NULLIF 防止除零）

最容易被忽略的是：这个陷阱不报错，只静默返回错误数值。上线后才发现报表里的“平均单价”总是偏低、“完成率”总是 0%，排查成本远高于写的时候多敲几个字符。