MySQL中SUM()对FLOAT/DOUBLE求和出现精度误差（如0.30000000000000004）是IEEE 754标准导致的必然现象，根本原因是十进制小数在二进制中无法精确存储；应从数据类型（优先用DECIMAL）、计算时机（聚合前转定点数）、比较逻辑（避免直接等值比较）三方面解决。
MySQL 的 SUM() 对 FLOAT 或 DOUBLE 列求和时出现 0.30000000000000004 这类结果，不是 bug，而是 IEEE 754 浮点数标准的必然表现——十进制小数在二进制中无法精确表示。 解决它不能靠“修显示”，得从数据类型、计算时机、比较逻辑三处动手。
为什么 FLOAT 类型 SUM 后小数位爆炸
根本原因是存储层就失真：FLOAT 把 0.1 存成近似二进制值（如 0.10000000149011612），多次累加后误差放大。哪怕只加两行 0.1 + 0.2，SUM() 返回的也不是数学意义上的 0.3，而是一个带尾数的近似值。
常见错误现象：
- WHERE 条件写
SUM(price) = 30.0永远不命中 - 前端展示金额出现
¥99.99999999999999 - 导出 CSV 后 Excel 自动转成科学计数法
用 DECIMAL(10,2) 替换 FLOAT 是最彻底的方案
DECIMAL 是定点数，按十进制字面量精确存储，SUM 过程不引入额外误差。但要注意：改类型不只是 ALTER COLUMN 那么简单。
实操建议：
- 建表时直接定义：
price DECIMAL(10,2)—— 10 位总长，2 位小数，够覆盖万元级金额 - 已有
FLOAT表需迁移：先ALTER TABLE sales MODIFY price DECIMAL(10,2)，再UPDATE sales SET price = ROUND(price, 2)清洗存量数据 - 别忽略应用层：如果 ORM 或中间件把 DECIMAL 当字符串传，可能触发隐式转换回 double，查日志确认实际绑定类型
CAST(SUM(...), DECIMAL) 和 ROUND(SUM(...), 2) 的区别
两者都能“压平”小数位，但语义和风险不同：
-
ROUND(SUM(price), 2)：先算浮点和，再四舍五入——误差已发生，只是被掩盖；适合快速修复报表展示 -
SUM(CAST(price AS DECIMAL(10,2)))：每行先转定点数，再累加——全程无浮点参与；精度真正可控 - 更稳妥写法：
CAST(SUM(CAST(price AS DECIMAL(10,2))) AS DECIMAL(10,2))，避免中间结果溢出或隐式提升为 double
注意 PostgreSQL 的 ROUND() 默认用银行家舍入（偶数优先），MySQL 是传统四舍五入，跨数据库迁移时行为可能不一致。
GROUP BY + SUM 场景下容易被忽略的坑
当分组依据本身是浮点字段（比如按 ROUND(unit_price, 1) 分组），或分组后对浮点列 SUM() 再 ROUND()，会出现“同值不同组”或“分组消失”。
关键点：
- 不要把
ROUND()放进GROUP BY子句——改用CAST(unit_price AS DECIMAL(10,1))确保分组键稳定 - 聚合后立即
ROUND()，别等 JOIN 或子查询后再处理，链式计算会累积误差 - CTE 或子查询中若涉及浮点列，显式
CAST每个中间列，否则优化器可能保留原始类型
财务、计费类业务里，连临时表字段、窗口函数的 OVER 子句里的表达式，都该默认走 DECIMAL 路线——精度问题从来不是“看起来一样就行”的事。
