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

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

差错不在算法而是类型，金额用浮点数存，本身就存不准。这篇把这个坑讲透，再说清金额该怎么存、已经踩坑的表怎么改。

## 一、浮点数存的是近似值，不是精确值

很多人遇到对账差钱，第一反应是代码算错了。这次真不是。代码逻辑我逐行看过，加减乘除都对。问题出在数据被存进去的那一刻，它就已经不精确了。

打开 MySQL 敲一行就能看见：

```sql
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 有效数字多，拿来存金额够用。绝大多数时候确实看不出问题。但只要量级够大、累加够多，它一样会漂。这不是概率问题，是迟早的问题。

## 四、实测：同一批金额，三种类型各跑一遍

光说原理没说服力，我建了张表把三种类型摆一起测。

```sql
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，分别塞进三种类型再读回来：

```sql
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。三种类型分别求和：

```sql
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 不翻车。想通这一点，金额该用哪个就清楚了。

## 五、更阴的坑：等值比较和索引

累加漂移还算看得见。浮点数真正阴的地方，是等值查询悄悄失效。

```sql
-- 用 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，而且一定用字符串构造：

```java
// 别这样：会用 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，改是能改的，但别一把梭。

改列类型本身不难：

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

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

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


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

财务对账差三毛的根因：金额字段浮点精度丢失原理与DECIMAL改造实战

一次财务对账差三毛钱的排查，牵出金额字段用浮点数的老坑。从IEEE 754为什么存不准0.1讲起，用同一批金额把FLOAT、DOUBLE、DECIMAL三种类型实测对比，再给出金额字段的选型、聚合与改表做法，附避坑清单。

编程语言

金额存储用浮点型会积累误差，导致对账差钱。本文实测对比FLOAT、DOUBLE和DECIMAL，揭露浮点数存金额的隐患，并给出改表方案、应用层避坑建议，助你彻底告别金额精度问题。

代码解释

数据库

Python

MySQL

Java

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

财务对账差三毛的根因：金额字段浮点精度丢失原理与DECIMAL改造实战-腾讯云开发者社区-腾讯云

财务对账差三毛的根因：金额字段浮点精度丢失原理与DECIMAL改造实战

财务对账差三毛的根因：金额字段浮点精度丢失原理与DECIMAL改造实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐