SQL中AVG函数注意整数除法陷阱

踩过坑的朋友都知道，SQL里有个容易忽视的细节，就是 A VG() 函数碰上整数类型列时，结果会悄悄“缩水”。这可不是什么玄学，而是整数除法在作祟。

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

问题出在数据类型上。当你的列是 INT、TINYINT 这类整数时，多数数据库（比如 MySQL、SQL Server、PostgreSQL）在执行 A VG() 时，会先乖乖地求和，然后用整数除法去除以行数。整数除法嘛，大家都知道，结果的小数部分直接“咔嚓”掉，连个招呼都不打。

举个例子，三个分数 80, 90, 99，平均分应该是 89.666...，但这么一搞，结果可能直接变成 89。这不是简单的显示问题，是计算过程本身就在截断——连 ROUND() 函数都救不回来，因为送进去的就已经是个整数了。

不同数据库的“截断”风格还略有不同：

• MySQL 默认会对整数列返回 DECIMAL 类型，但精度可能不够，比如只给你保留一位小数。
• SQL Server 和旧版 PostgreSQL 就更直接了，整数列的结果就是整数，小数点后面的东西？不存在的。
• Oracle 的行为则取决于列定义和数据库版本，但核心问题是一样的。

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

核心思路其实很简单：在除法发生的那一刻之前，就把至少一个操作数变成浮点数或高精度类型。下面这几种写法是业界共识，兼容性也还不错：

• 最稳妥的写法：CAST(列名 AS DECIMAL(10,2))。这种方式显式控制了精度，推荐在报表场景下使用，一眼就能看出要保留几位小数。
• 简洁一点：列名 * 1.0 或 列名 * 1.00。这种方法利用了隐式转换，但不同的数据库对小数位数的处理有细微差别，有时候会出点小意外。
• SQL Server 专属：CONVERT(DECIMAL(10,2), 列名)，功能上和 CAST 一样。

实战中，SELECT A VG(CAST(amount AS DECIMAL(10,2))) FROM sales; 显然比 SELECT A VG(amount) FROM sales; 要可靠得多。

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

这里有个非常经典的误区。很多人以为用 ROUND() 包一下 A VG() 就能解决，但这是完全错误的。ROUND() 是对 A VG() 的最终输出结果做四舍五入。如果 A VG() 内部已经按照整数除法算出了 89，那 ROUND(89, 2) 的结果依然是 89.00，丢失的小数部分永远无法还原。

下面两个场景，是新手非常容易踩的坑：

• SELECT ROUND(A VG(score), 2) FROM students; —— 如果 score 是 INT 类型，这个操作就是无效的，因为 A VG(score) 已经是个整数了。
• SELECT A VG(score) AS a vg_score FROM students; —— 看起来没问题，但数据导出到 Excel 或在前端展示时，你可能会发现平均分全是整数，那时候再排查，就晚了。

记住，真正的解决之道，必须干预除法环节本身，而不是事后做表面功夫。

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

这个陷阱可不只 A VG() 函数有。任何显式除法，比如计算完成率 (success_count / total_count) * 100，只要两个字段都是整数，结果就是 0（当分子小于分母时）。这种“静默”错误，简直防不胜防。

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

• 可以写成 (success_count * 1.0 / total_count) * 100。
• 更严谨的写法是 CAST(success_count AS DECIMAL(10,2)) / NULLIF(total_count, 0) * 100，这里的 NULLIF 是为了防止除零错误。

最容易被忽视的一点是：这个陷阱永远不会报错，它只会静悄悄地返回一个错误数值。等到上线后，发现报表里的“平均单价”总是偏低，“完成率”总是 0%，那时候排查问题的成本，可比写代码时多敲几个字符高多了。