MySQL 金额字段怎么选 DECIMAL 的精度和小数位

设计订单金额、账户余额或商品单价时，DECIMAL(10,2) 不是可以无脑套用的答案。更稳妥的做法是先确定“最大整数金额”和“最小计量单位”，再用 M、D 反推字段：D 是小数位，M-D 才是整数位容量。比如只保存元和分，且业务允许最大到 99999999.99，可以使用 DECIMAL(10,2)；如果还要保存千分之一，就要增加小数位，同时重新计算总位数。

先把 DECIMAL(M,D) 读懂，再确定金额范围

MySQL 文档把 DECIMAL 和 NUMERIC 定义为精确数值类型，适合需要保留精度的金额数据。DECIMAL(M,D) 里的 M 是总有效位数，D 是小数点右侧的位数，因此整数位数量是 M-D。

例如 DECIMAL(5,2) 有 5 位总精度、2 位小数，整数部分只剩 3 位，通常可表示 -999.99 到 999.99。这里的“5”不是整数位长度；把它误当成“最多五位整数”是金额字段最常见的坑。

按业务上限倒推精度和小数位

选型时可以固定成三个问题：最大可能金额是多少？最小单位需要到几位小数？金额是否允许为负？如果金额上限是 8 位整数、固定到分，字段至少要有 8+2=10 位总精度，也就是 DECIMAL(10,2)。若还要表示毫厘，则小数位变成 3，字段至少应为 DECIMAL(11,3)。

CREATE TABLE orders (
  id BIGINT UNSIGNED PRIMARY KEY,
  -- 金额允许 8 位整数、2 位小数；是否允许负数由业务约束决定
  amount DECIMAL(10, 2) NOT NULL,
  -- 折扣率与金额不同，按业务最小单位单独确定精度
  discount_rate DECIMAL(6, 3) NOT NULL DEFAULT 0.000
);

不要为了“以后可能变大”直接把所有字段设为 DECIMAL(65,30)。精度越大，字段语义越模糊，接口校验、报表格式和跨系统映射也越难统一。更实际的做法是按单笔上限、日累计上限和历史数据迁移空间分别估算，并把计算依据写进表设计说明。

用建表与写入实验检查边界

定义完成后，至少检查一个正常值、一个多出小数位的值和一个超过整数范围的值。下面的示例只用于验证字段行为，不需要把真实订单数据带进测试表。

SET sql_mode = 'TRADITIONAL';

CREATE TABLE amount_probe (
  id INT PRIMARY KEY,
  -- 用较小范围让边界在测试中一眼可见
  amount DECIMAL(5, 2) NOT NULL
);

-- 正常值：整数位 3 位、小数位 2 位
INSERT INTO amount_probe (id, amount) VALUES (1, 12.34);
-- 多出小数位：观察写入后的 scale 转换结果
INSERT INTO amount_probe (id, amount) VALUES (2, 12.345);
-- 超过 999.99：严格模式下应以越界错误终止
INSERT INTO amount_probe (id, amount) VALUES (3, 1000.00);

SELECT id, amount FROM amount_probe ORDER BY id;

严格 SQL mode 下，超出字段范围的值会被拒绝；非严格模式下，MySQL 可能把值裁剪到边界并产生警告。小数位超过 D 时则会按字段 scale 转换，所以金额在进入数据库前仍应由应用层明确舍入规则，不能把数据库字段当成业务计费规则。

生产表设计时别漏掉舍入和溢出

金额字段真正上线前，再做四项检查。第一，确认正负号：退款、冲正或账务差额是否允许负数。第二，确认汇总结果：单笔字段够用，不代表 SUM(amount) 的长期累计也够用。第三，确认应用语言使用十进制定点类型或字符串传递，避免先在二进制浮点数中计算后再写入。第四，在迁移和批量导入环境中确认 SQL mode 一致，并把越界当作需要处理的错误，而不是等警告被忽略。

如果业务只允许非负金额，可以在应用层和数据库约束层同时表达；如果是高风险账务，还应保留原始输入、舍入方式和变更记录。字段定义解决的是存储精度，不会自动解决多币种换算、税费舍入或分摊尾差。

常见问题

金额字段可以用 DOUBLE 吗？

展示型、近似型统计可以讨论浮点数，但订单金额、余额、支付和账务明细通常应优先使用精确数值方案。核心不是“能不能存”，而是计算和比较时是否允许近似误差。

DECIMAL(10,2) 能保存多少金额？

它有 8 位整数位和 2 位小数位，常见有符号范围可理解为 -99999999.99 到 99999999.99。实际写入仍应通过目标 SQL mode 和字段实验确认。

小数位设置得越多越好吗？

不是。小数位应对应业务最小单位和结算规则；多余位数会增加接口、展示和跨系统转换成本。先确定业务精度，再为未来增长预留合理整数位。