大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
月初财务拿着一张表来找我。系统导出的手续费总额，跟银行流水差了三毛钱。三毛不多，可账对不上就是大事。我把那个月的流水全导出来，算了一晚上。最后定位到的不是代码，是建表时那个金额字段，它被写成了 DOUBLE。
差错不在算法而是类型，金额用浮点数存，本身就存不准。这篇把这个坑讲透，再说清金额该怎么存、已经踩坑的表怎么改。
一、浮点数存的是近似值，不是精确值
很多人遇到对账差钱，第一反应是代码算错了。这次真不是。代码逻辑我逐行看过，加减乘除都对。问题出在数据被存进去的那一刻，它就已经不精确了。
打开 MySQL 敲一行就能看见：
SELECT 0.1 + 0.2;
-- 结果：0.30000000000000004
0.1 加 0.2，得到 0.30000000000000004。这不是 MySQL 的 bug，换任何语言、任何数据库都一样。这是 IEEE 754 浮点标准的规矩。你写的是 0.1，机器里存的却是离 0.1 最近的那个二进制小数。
这个差有多小？小到单条数据看不出来。它真正要命的地方，是成千上万条累加之后，误差越滚越大，最后滚成对账差的那三毛钱。
二、为什么 0.1 存不准：十进制和二进制对不上
计算机存数字用二进制，小数点后也是。问题在于不是每个十进制小数都能用二进制精确表示。
整数好办，2、4、8 都能精确转成二进制。小数就麻烦了。0.5 可以，0.25 可以，因为它们是 2 的负幂次。但 0.1、0.2、0.3 这些，转成二进制是无限循环小数，像 0.0001100110011... 一直循环下去。
而一个浮点数的尾数位数是有限的。它存不下无限循环，只能在某一位截断。截断就意味着舍入，舍入就意味着误差。这个误差叫表示误差，从数据写入那一刻就产生了。
平时做一次查询，表示误差小到看不出来。可一旦涉及金额的累加、求和、分组统计，误差会一条条累加。这就是为什么对账这种需要分毫不差的场景，最怕浮点数。
三、三种类型，底层差在哪
MySQL 存带小数的数字，有三种常见类型：FLOAT、DOUBLE、DECIMAL。前两个是浮点类型，最后一个是定点类型。它们的底层存法完全不同。
FLOAT 占 4 字节，尾数 24 位，大概能精确到 7 位有效数字。DOUBLE 占 8 字节，尾数 53 位，能到 15 到 16 位。DECIMAL 不一样，它不按浮点存，而是按整数位存，小数点的位置固定，位数由定义时的 M 和 D 决定。
关键区别在这里。FLOAT 和 DOUBLE 是近似类型，MySQL 官方文档写得很清楚，它们存的是近似值。DECIMAL 是精确类型，你存 1.23，读出来就是 1.23。
| 类型 | 存储方式 | 有效数字 | 是否精确 | 占用 |
|---|---|---|---|---|
| FLOAT | IEEE 754 | 约 7 位 | 否 | 4 字节 |
| DOUBLE | IEEE 754 | 约 15 位 | 否 | 8 字节 |
| DECIMAL | 定点整数存储 | 由 M/D 定 | 是 | 按位数确定 |
有人图省事，觉得 DOUBLE 有效数字多，拿来存金额够用。绝大多数时候确实看不出问题。但只要量级够大、累加够多，它一样会漂。这不是概率问题，是迟早的问题。
四、实测：同一批金额，三种类型各跑一遍
光说原理没说服力，我建了张表把三种类型摆一起测。
CREATE TABLE pay_test (
id INT AUTO_INCREMENT PRIMARY KEY,
amt_float FLOAT,
amt_double DOUBLE,
amt_decimal DECIMAL(12,2)
) ENGINE=InnoDB;
先看单值存储。同一笔 1234567.89，分别塞进三种类型再读回来：
SELECT CAST(1234567.89 AS FLOAT) AS f,
CAST(1234567.89 AS DOUBLE) AS d,
CAST(1234567.89 AS DECIMAL(12,2)) AS c;
-- f: 1234567.9 d: 1234567.89 c: 1234567.89
FLOAT 这一笔就丢了约一分五，读回来成了 1234567.9。DOUBLE 和 DECIMAL 这次扛住了。单笔就丢分，已经很能说明 FLOAT 的脾气。
再看累加。我灌了 100 万行，每笔手续费 0.29 元，理论合计正好 290000.00。三种类型分别求和：
SELECT SUM(amt_float) AS s_float,
SUM(amt_double) AS s_double,
SUM(amt_decimal) AS s_decimal
FROM pay_test;
| 类型 | 100 万行求和 | 与 290000.00 的偏差 |
|---|---|---|
| FLOAT | 290000.28 | 漂了约 0.28 元 |
| DOUBLE | 290000.0000002 | 几乎为 0 |
| DECIMAL | 290000.00 | 0 |
FLOAT 累加漂了快三毛，这就是财务找上门的那笔差额。DOUBLE 在这个量级还稳得住，但别高兴太早。数值是测试机的实测结果，不同版本、不同硬件会有出入，趋势是稳定的：精度越低漂得越凶。
FLOAT 早点翻车，DOUBLE 晚点翻车，DECIMAL 不翻车。想通这一点，金额该用哪个就清楚了。
五、更阴的坑：等值比较和索引
累加漂移还算看得见。浮点数真正阴的地方，是等值查询悄悄失效。
-- 用 DOUBLE 存金额时，下面这句查不到你想要的行
SELECT * FROM orders WHERE amount = 0.30;
原因和前面一样。0.3 在 DOUBLE 里是个近似值，你插入时写的 0.3，和查询时写的 0.3，舍入方式一样，可能碰巧相等。但在乘法、除法、聚合之后，两边的近似值就可能错开最后几位，导致本该相等的不再相等。
对账恰恰靠等值匹配。流水和订单按金额字段 JOIN，金额一旦带浮点误差，本该配上的记录就配不上，凭空多出一堆差异项。这不是偶发，只要涉及计算，迟早会遇到。
DECIMAL 没有这个问题，它的比较是精确的。金额做等值、做去重、做对账匹配，必须落在精确类型上。这条没有商量余地。
六、金额到底该怎么存
结论其实很清楚：金额字段用 DECIMAL，别用 FLOAT，也别用 DOUBLE。
先定长度。DECIMAL 的写法是 DECIMAL(M,D)。D 是小数位数，人民币业务固定 2 位，写 2。M 是总位数，包含小数位，按业务最大金额估。一般订单金额 DECIMAL(12,2) 够用，能存到百亿级。涉及对账汇总的字段，位数留宽一点，别等业务涨了再改表。
大小写清了，还得管住应用层。数据库存对了，代码里翻车一样白搭。Java 里千万别用 double 做金额运算，它是八字节浮点，和 DOUBLE 一个毛病。改用 BigDecimal，而且一定用字符串构造：
// 别这样：会用 double 的近似值
new BigDecimal(0.1); // 0.10000000000000000555...
// 要这样：按字符串精确构造
new BigDecimal("0.1"); // 0.1
Python 同理，金额用 Decimal，别用 float。JS 用整数分，或者专门的金额库。只要金额沾了浮点，后面都得还债。
还有个细节。聚合和分摊这类要除法的场景，别让中间结果早早截断。先乘后除、保留足够中间精度，最后一步再舍入。分摊一块钱给三个人，每人本该 0.333333，提前舍成 0.33，三个人加起来就少了三分，这类尾差在对账时全是坑。
顺带说一句，不同库对数值类型的实现有差异。像金仓KES这类国产库，DECIMAL是标准实现，精度语义和主流库一致。更省事的是，它的KDMS迁移评估工具会自动扫描源端的类型定义，把FLOAT/DOUBLE金额列标出来，提示你必须转成DECIMAL。真要换库，重点核对的就是这些历史遗留的浮点金额列，别把老毛病一起带过去。
七、已经踩坑的表，怎么改
如果表已经建成了 FLOAT 或 DOUBLE，改是能改的，但别一把梭。
改列类型本身不难：
ALTER TABLE orders
MODIFY amount DECIMAL(12,2) NOT NULL;
难点在大表。改列类型会触发表重建，几千万行的表直接执行，锁表时间长，线上扛不住。线上的做法是走 Online DDL，或者用 gh-ost、pt-online-schema-change 这类工具做在线变更，避开业务高峰，一步步来。
比改类型更麻烦的，是历史数据。旧的浮点数已经带了误差，直接 CAST 成 DECIMAL 只是把误差固化下来，精确不了。金额列的历史数据，能按业务重新算的，就重新算。算不了的，至少留一份回溯记录，明确哪些是历史脏数据。
改完必须验。拿改后的数据重跑一遍对账，跟银行流水、跟业务系统逐笔比对。数字对上了，才算改完。
避坑清单
建表定类型时就把金额落到 DECIMAL，别用 FLOAT，也别用 DOUBLE。等上线发现对账差钱再改，大表改类型的代价，比一开始多花一分钟定义字段大得多。
应用层的金额运算和数据库是两回事，得一起管。数据库用 DECIMAL，代码里却用 double 相加，等于前脚刚擦干净、后脚又踩进去。Java 用 BigDecimal 字符串构造，Python 用 Decimal，这条和选库一样的优先级。
已经用浮点存了金额的老表，改之前先想清楚两件事：历史数据怎么修正，线上大表变更怎么不停机。想不清楚就别急着改，先加一层对账监控把差异暴露出来，再定改造方案。
写在最后
金额这道题，说到底是问一句：这个数要不要分毫不差。要，就上 DECIMAL，没别的选。浮点数本身没问题。科学计算、坐标、图像，它又快又省。只是它不适合拿来存钱。金额差一分，会计的账就过不了，这跟差一百万没区别，都是错。
我现在建表定金额，手都是条件反射：DECIMAL，两位小数，位数往宽了留。这个习惯是被那三毛钱教会的。
你手里的表，金额字段用的是哪种类型？有没有在对账时被浮点数坑过？评论区聊聊，我猜不少人都跟那三毛钱打过照面。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
