聊数据库里的 numeric，可能很多刚入行的朋友会觉得这是老生常谈。毕竟在 MySQL 里用 decimal，在 PostgreSQL 里用 numeric，好像就是存小数的工具。但实际干了几年活的老炮都知道，这东西用不对，能让你在月底对账时哭出来。我见过最惨的案例，是某电商公司财务系统里，订单金额用 float 存，结果满 100 减 50 的优惠券算出来显示 49.99 元。用户投诉说系统黑了他们的钱，客服解释了半天也没用，最后发现是浮点数精度问题。所以今天咱们就把 numeric 该怎么用说清楚。
先说最常见的坑：很多人分不清 numeric 和 decimal 的区别。SQL 标准里这俩其实是同义词，但不同数据库实现有细微差别。比如在 SQL Server 里，decimal 和 numeric 完全一样，都能指定精度和标度；在 Oracle 里，numeric 默认是 38 位精度，decimal 则可能被当作 number 类型处理。最要命的是 MySQL，它把 decimal 当字符串处理，而 numeric 只是 decimal 的别名。所以跨库迁移时千万不能想当然。建议不管用哪个数据库，都统一使用 decimal(n,m) 这种写法，因为大多数 ORM 框架都优先支持它。另外，精度 n 和标度 m 的设定要讲究。n 是总位数，m 是小数位数。比如 decimal(10,2)，整数部分 8 位，小数部分 2 位。很多人觉得设个 decimal(18,2) 就保险了，但如果你存的是美元兑日元这种汇率，小数点后四位才够用，设成 2 位就会丢精度。
再来说说性能问题。有些开发喜欢把所有金额字段都设成 decimal(18,2)，觉得这样够用。但如果表里存了上千万笔交易，每次做聚合计算时，numeric 类型的计算开销比整数型高一个数量级。我见过一个极端案例：某金融公司日终清算用 numeric 存所有交易金额，跑批要 4 小时，改成用 bigint 存分单位金额后，跑批时间直接降到 20 分钟。当然，这取决于业务场景。如果只是存订单金额，一天几万笔，decimal 完全够用。但如果是高频交易系统或大数据分析的数仓，建议用整数型代替 numeric，比如统一用“分”存，这样既避免了精度问题，又提升了性能。显示时记得除以 100，前端别忘了格式化。
还有一个让人头疼的问题：numeric 在计算中的隐式转换。比如字段 price 是 decimal(10,2)，在 SQL 里写 ，你以为结果还是 decimal，实际数据库可能会把结果转成 float 或 double，导致折扣后出现一串奇怪的数字。解决办法很简单：把常量也声明成 decimal。比如 ，或者直接写 （有些数据库会自动识别）。最保险的做法是，所有涉及金额的计算都封装成存储过程或函数，在内部统一处理类型转换，这样后期维护时不会因为新人写了 就出幺蛾子。
接着说一个容易被忽略的点：numeric 字段的存储空间。很多人以为 decimal(10,2) 存起来就是 10 个字节，实际上不是。以 MySQL 为例，decimal 的存储是每 9 位数字占 4 个字节。decimal(10,2) 共 10 位数字，需要两个 4 字节块，再加一点开销，实际占用 9 个字节。如果改成 decimal(18,2)，18 位数字需要三个 4 字节块，即 13 个字节。所以如果表里有大量 decimal 字段且数据量上亿，这个存储差异相当可观。我曾把一个系统的几十个 decimal(18,2) 改成 decimal(10,2)，表空间直接省了约 30%。前提是业务确实不需要那么高的精度。比如用户积分字段，最多几百万分，decimal(10,0) 就够了，没必要用 decimal(18,2)。
再聊实战中常遇到的情况：numeric 在分库分表或微服务场景下的兼容性问题。比如订单服务用 PostgreSQL，财务服务用 Oracle，两个系统通过消息队列传递金额数据。如果一方用 numeric，另一方用 decimal，序列化成 JSON 时可能会把 numeric 转成字符串，甚至丢失精度。我就踩过这个坑：对接第三方支付平台时，对方要求金额字段必须是字符串且保留两位小数，我们直接传了 numeric，结果对方反序列化后出现科学计数法，导致对账失败。后来我们在 API 网关层统一做转换，所有金额字段先转成字符串再传输。最好的做法是，系统内部统一使用分单位的整数传递，只在展示层转成 decimal，这样既避免跨语言类型问题，又保证精度。
说个趋势：随着云原生和 Serverless 的普及，很多开发开始用 NoSQL 或 NewSQL 数据库，比如 TiDB、CockroachDB，它们对 numeric 的支持各有不同。TiDB 兼容 MySQL 的 decimal 语法，但底层存储用整数实现，性能比 MySQL 更好；CockroachDB 的 numeric 实际是浮点数包装，精度不如传统关系型数据库。如果准备上云原生数据库，一定要先做压力测试，看看 numeric 在高并发下的表现。我见过一个案例，某公司从 MySQL 迁移到 CockroachDB 后，财务系统每个月的对账差一分钱，查了三天才发现是 numeric 精度问题。
回到开头的问题：numeric 到底该怎么用？我的建议是，能不碰 numeric 就别碰。能用整数解决的，比如金额用分存、时间戳用毫秒存，就坚决不用 numeric。但如果必须使用，比如存汇率、利率这种天生带小数的数据，记住几个原则：精度宁高勿低，但不要盲目设成 18,2；所有计算都显式转换类型；跨系统传递时统一转成字符串。写一个单元测试，专门验证系统里所有涉及 numeric 的运算，看看是否有精度丢失。别等上线后才发现问题，那就晚了。
