金额字段存储最佳实践：浮点精度问题与DECIMAL选型指南

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

月初财务拿着一张表来找我。系统导出的手续费总额，跟银行流水差了三毛钱。三毛不多，可账对不上就是大事。我把那个月的流水全导出来，算了一晚上。最后定位到的不是代码，是建表时那个金额字段，它被写成了 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。

有人图省事，觉得 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;

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，两位小数，位数往宽了留。这个习惯是被那三毛钱教会的。

你手里的表，金额字段用的是哪种类型？有没有在对账时被浮点数坑过？评论区聊聊，我猜不少人都跟那三毛钱打过照面。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋