在应用开发中，尤其是在处理金额数据时，使用浮点数（如 Java 的 Float 对应 MySQL 的 FLOAT）是一个常见的误区。本文将深入分析一个实际案例：数据在 Java 应用层具有小数精度，但存储到 MySQL 中却诡异地被截断到个位。
问题描述：浮点数的精度去哪了？
在一个处理薪资数据的模块中，我们观察到一个反常现象：
- 数据类型定义：MySQL 表字段被定义为标准的
FLOAT类型（未指定精度，如FLOAT(10, 2)）。 - 应用层状态：Java 后端使用
Float类型存储日工资/月工资，并通过 Mybatis 传递到数据库。通过日志和断点确认，在 SQL 执行之前，数值（例如141707.8）是正确的浮点数。 - 结果：直接查询数据库，发现存储的值被限制到个位（例如
141707.8变成了141707或141708），小数部分完全丢失。
核心矛盾： 为什么一个设计上支持小数的 FLOAT 字段，会无故将传入的小数部分截断？
🛠️ 解决思路与原理解析
通过全链路排查，我们排除了 Java 实体类类型错误、应用程序代码截断等常见问题，最终将目标锁定在 MySQL 的 FLOAT 字段定义上。
根源分析：MySQL FLOAT 的默认行为陷阱
标准的 FLOAT 类型在 MySQL 中默认是 4 字节的单精度浮点数。当我们使用 FLOAT （不带 M, D 参数） 定义字段时，相当于让 MySQL 使用其内部的默认浮点数存储逻辑。
在某些特定的 MySQL 版本或配置下，当数据通过 JDBC 驱动写入没有显式精度约束的 FLOAT 字段时，数据库可能会采用一种保守或不兼容的存储/显示机制，导致它**截断（或显示为截断）**小数部分，尤其是在与 Java Float 交互时。
临时的技术解法：显式指定精度 FLOAT(M, D)
解决这一问题的直接方法是打破这种默认行为，通过在字段定义时显式指定总位数（M）和小数位数（D），强制 MySQL 按照预期的精度存储数据。
SQL 修复语句示例：
SQL
ALTER TABLE cost_of_lost_labour_data
MODIFY COLUMN list_of_proof_of_income_flow_daily_wages FLOAT(10, 2) NOT NULL COMMENT '工资证明日工资';
当定义为 FLOAT(10, 2) 后：
- 强制精度： MySQL 被告知该字段需要保留小数点后两位。
- 四舍五入： 数据库将对传入的值进行四舍五入到 2 位小数，而不是粗暴地截断到个位。
实验证明，这一改动成功解决了小数被限制到个位的问题。
💡 终极忠告：金额存储的行业最佳实践
虽然 FLOAT(10, 2) 解决了当前的 Bug，但对于金额或任何需要高精确度的数值，业界强烈不建议使用任何浮点数类型（FLOAT 或 DOUBLE）。
为什么不能用 FLOAT/DOUBLE？
FLOAT 和 DOUBLE 是近似数值类型，它们使用二进制浮点表示法（IEEE 754 标准），无法精确表示所有十进制小数（例如 0.1 在二进制中是无限循环小数）。
这会导致计算结果出现微小的舍入误差，例如：10.20 + 20.30 最终可能存储或计算为 30.500000000000004。在财务和会计领域，任何微小的误差都是不可接受的。
最佳实践：使用 DECIMAL 和 BigDecimal
对于金额数据，应遵循以下黄金标准：
| 组件 | 数据类型 | 作用 |
| 数据库 | DECIMAL(M, D) | 精确数值类型 (Exact Numeric Data Type)。以字符串形式存储，保证完全精确，无精度损失。推荐格式如 DECIMAL(10, 2) 或 DECIMAL(13, 4)。 |
| Java 应用 | java.math.BigDecimal | 对应 DECIMAL，提供精确的十进制运算能力，避免 Java 语言中 Float/Double 的计算误差。 |
📝 问题总结与经验提炼
本次排查暴露了两个核心问题：
- MySQL 陷阱： 在 MySQL 中定义
FLOAT字段时，如果未指定(M, D)精度，可能触发隐式的、不预期的小数截断行为。 - 技术选型错误： 金额数据是典型的精确值，使用浮点数 (
FLOAT/DOUBLE) 从根本上就引入了精度风险。
最终建议：
对于所有涉及金钱、库存或任何需要绝对精确度的数字，请立即切换数据类型：数据库使用 DECIMAL，应用层使用 BigDecimal。将 FLOAT 仅保留给那些可以接受少量误差的科学计算或统计数据。
