FLOAT在SQL中返回值与存入值不同，是因为其按IEEE 754二进制浮点格式存储，而0.1等十进制小数在二进制中无限循环，必须截断导致写入即失真，查询结果自然不一致。
为什么FLOAT在SQL查询里返回的值和存进去的不一样
因为 FLOAT（包括 REAL、DOUBLE PRECISION）在数据库里不是按十进制存的，而是按 IEEE 754 二进制浮点格式存的。像 0.1、0.11、-0.11105 这类小数，在二进制下是无限循环小数，必须截断存储——这就导致写入时已经失真，查出来自然“不对”。你看到的 -0.111049999999 或 0.10000000149012 不是传输或显示问题，是它本来就被这么存的。
MySQL/PostgreSQL/SQL Server 的 FLOAT 查询差异在哪
三者底层都用 IEEE 754，但默认行为略有不同：
- MySQL 的
FLOAT默认是单精度（约 6–7 位有效数字），DOUBLE是双精度（约 15–17 位）；设DOUBLE(5,3)这类精度限制只是控制显示/插入时的舍入，并不改变底层存储方式 - PostgreSQL 的
REAL≈FLOAT，DOUBLE PRECISION≈FLOAT8；但查询时如果用 MyBatis +BigDecimal接收FLOAT8字段，会触发额外的二进制→十进制转换误差，导致结果不稳定 - SQL Server 的
FLOAT默认就是双精度，但SUM()累加过程中的每一步都会引入新舍入误差，百亿级求和偏差达数万元就是这么来的
什么时候查 FLOAT 会“看起来正常”，什么时候崩
是否“看起来准”，取决于你观察的粒度和数值本身能否被有限位二进制精确表示：
-
0.25、0.5、0.375这类分母是 2 的幂次的小数，二进制可精确表示 → 查询显示通常没问题 -
0.1、0.11、0.7这类绝大多数小数，二进制无限循环 → 存、取、算全阶段都可能暴露误差 - 单纯
SELECT * FROM t WHERE f = 0.1很可能查不到数据，因为存进去的压根不是0.1，而是最接近它的二进制近似值 - 用
ROUND(f, 2)显示能掩盖问题，但改不了底层失真；一旦参与JOIN、GROUP BY或导出到 JavaDouble，误差立刻复现
真正管用的修复动作只有两个
别在 FLOAT 上打补丁，直接换类型或换用法：
- 金额、指标值、时间戳等**必须精确**的字段：建表时就用
DECIMAL(p,s)（MySQL/PostgreSQL）或NUMERIC(p,s)（SQL Server）；迁移存量数据时，用CAST(old_col AS DECIMAL(15,6))而不是ALTER COLUMN ... TYPE DECIMAL直接转，避免隐式截断 - 需要跨语言一致计算（比如 Java 和 SQL Server 校验总和）：两端统一用
DECIMAL+BigDecimal，禁用FLOAT/double一切中间环节；VARCHAR 存数字再转 FLOAT 是双重灾难，必须杜绝
精度丢失不是数据库 bug，是二进制表示十进制小数的必然代价。只要字段语义要求“所见即所得”，FLOAT 就不该出现在 DDL 里——哪怕只差 0.000001，也可能让对账脚本跑出 33 万元偏差。
