根本原因是FLOAT/DOUBLE二进制精度限制导致小数存储误差，SUM()仅忠实返回结果；传100和100.0因MySQL字面量类型推导不同而精度丢失；混合DECIMAL精度时SUM()自动升阶可能引发截断；空集或全NULL使SUM()返回NULL而非0；需从源头用DECIMAL+显式CAST+标度声明防控。
根本原因不是 SUM() 本身有问题，而是参与计算的数值类型是 FLOAT 或 DOUBLE —— 它们用二进制近似表示十进制小数，0.1、0.2、0.3 这类数在二进制里是无限循环小数，存储和运算时必然截断，误差累积后 SUM() 只是忠实地返回了那个“看起来像 60.00 实际是 60.00000000001”的结果。
为什么传 100 和 100.0 给 DECIMAL 参数结果不同
MySQL 对字面量有默认类型推导规则：100 被当整型（INT），0.08 被当 DOUBLE；哪怕你函数参数声明为 DECIMAL(15,2)，只要调用时传的是裸数字，中间计算链就已转成 DOUBLE，精度当场丢失。
-
CALL calc(100.0, 0.08);✅ 末尾加.0是最轻量提示 MySQL 按十进制字面量处理 -
CALL calc(CAST(100 AS DECIMAL(10,2)), CAST(0.08 AS DECIMAL(5,4)));✅ 强制类型对齐，最稳妥 -
CALL calc(100, 0.08);❌0.08被解析为DOUBLE，乘法结果大概率变成DOUBLE类型
SUM() 遇到混合精度 DECIMAL 列时自动升阶规则
当 UNION ALL 或多表 JOIN 把不同精度的 DECIMAL 列合并后算 SUM()，MySQL 会按最大精度/标度推导结果类型，但容易超出预期——比如 DECIMAL(17,0) 和 DECIMAL(19,4) 合并，SUM() 结果可能是 DECIMAL(30,4)，若你用窄变量接收（如 DECIMAL(10,2)），就会静默四舍五入截断，不报错也不警告。
- 查当前列定义：
SHOW COLUMNS FROM sales LIKE 'amount'; - 显式统一精度再聚合：
SUM(CAST(amount AS DECIMAL(15,2))) - 避免隐式升阶失控：所有参与聚合的字段，提前
CAST到同一DECIMAL(M,D)
NULL 和空结果导致 SUM() 返回 NULL 而不是 0
SUM() 对空集或全 NULL 列返回 NULL，这不是精度问题，但常被误认为“计算错了”。应用层若直接取值不做判断，可能触发空指针或逻辑异常。
- 安全写法：
COALESCE(SUM(amount), 0)，强制补 0 - 验证是否有数据：
SELECT COUNT(*) FROM sales WHERE ...先跑一遍 - 注意：WHERE 条件过滤后无匹配行，
SUM()仍返回NULL，不是 bug
真正危险的是类型链断裂——某个中间值被当成 DOUBLE，后续所有计算都漂移，而 MySQL 不报错、不警告，只默默给你一个“看起来对”的错值。别依赖 ROUND() 事后修，从源头用 DECIMAL + 显式 CAST + 带标度声明，才是唯一可控路径。
