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%，排查成本远高于写的时候多敲几个字符。
