sum()和avg()结果“不对”主因是float/double类型存储不精确，如99.99实际存为99.98999999999998，误差从入库即固化；round()仅修饰显示，无法修复底层失真，须用decimal类型+cast清洗数据。
为什么SUM()和AVG()返回的浮点数看起来“不对”
不是函数算错了，而是输入值本身就不精确。如果你的字段是 FLOAT 或 DOUBLE 类型，比如存了个 99.99，实际入库的是 99.98999999999998 或 99.99000000000002。后续所有聚合——SUM()、AVG()、MAX()——都基于这个“假值”计算，误差从第一步就固化了。
常见现象包括：
-
SUM(price)显示为199.97999999999996而非预期的199.98 -
AVG(price)算出来是66.65999999999998，导致报表四舍五入后多出或少掉几分钱 - 用该结果再做除法（如人均消费）、比较（
> 100）时，边界行为不可靠
ROUND()套在聚合外面能修好吗
不能。ROUND(SUM(price), 2) 只是把已经失真的 199.97999999999996 截成 199.98 显示，底层值没变，也不影响后续计算逻辑。更危险的是，它会掩盖问题：你以为数据对了，其实只是“看起来对”。
真正有效的做法是让精度控制发生在聚合之前：
- 字段类型必须是
DECIMAL(M,D)，比如DECIMAL(15,2)存金额 - 如果已有
FLOAT字段，别指望改表结构就能自动修复存量数据——那些近似值不会自己变精确，得用UPDATE ... SET price = CAST(price AS DECIMAL(15,2))清洗一遍 - 聚合时直接用
SUM(price)，DECIMAL类型天然保持精度，不需要ROUND补救
子查询 + 浮点字段 + IN/JOIN 为什么会静默失败
这是最隐蔽的坑：SELECT * FROM orders WHERE user_id IN (SELECT user_id FROM payments WHERE amount = 99.99) 很可能查不到任何记录，哪怕你确认 payments 表里有 amount = 99.99 的行。
原因在于：子查询返回的 amount 是浮点近似值，外层 = 99.99 拿的是另一个字面量近似值，两者误差方向不同，相等判断几乎必为 false。
解决方式不是加容差（ABS(amount - 99.99) ），而是统一转定点数：
- MySQL：
CONVERT(amount, DECIMAL(10,2)) = 99.99 - PostgreSQL：
amount::DECIMAL(10,2) = 99.99 - SQL Server：
CAST(amount AS DECIMAL(10,2)) = 99.99
关键点：转换动作必须出现在参与比较的表达式内部，不能只在最终 SELECT 列里做。
聚合前用ROUND(price, 2)再求和，是不是更安全
更不安全。写成 SUM(ROUND(price, 2)) 相当于对每个原始浮点值单独四舍五入，再累加——这放大了舍入误差，尤其当原始值小数位数较多时（比如 price 实际是 FLOAT 存的 19.995 和 20.004，ROUND 后都变成 20.00，但它们本不该被同等对待）。
正确路径只有一条：源头用 DECIMAL，全程避免浮点参与任何中间计算。连存储过程参数、变量声明、常量传参（比如用 100.0 而非 100）都要保持 DECIMAL 链路不断。
最容易被忽略的是：错误一旦发生，数据库既不报错也不警告，只默默返回一个“看起来合理”的偏差值。财务对账差三毛，根源往往就藏在这条看似无害的 SUM(price) 里。
