说起数据库里的 numeric 类型，我第一反应是，这玩意儿真像是个“强迫症救星”。你想想，平时写代码时，用整数或浮点数，常常被精度问题搞得头大。比如存个价格，明明是 99.99，结果因为浮点数误差变成 99.9899，客户一看账单直接炸毛。这时候 numeric 就登场了，它不玩那些近似计算，而是死磕精确度，像老会计记账一样，一分钱就是一分钱。我接触数据库这些年，从 MySQL 到 PostgreSQL，再回到 Oracle，numeric 几乎无处不在。它有个外号，叫“定点数”，意思就是小数点后的位数固定死了，不像 float 那样飘忽不定。比如你定义 numeric(10,2)，表示总共 10 位数字，其中 2 位在小数点后，存钱进去，怎么算都不会跑偏。这特性特别适合金融、税务这类场景，数字错一点，可能就得吃官司。所以，别小看这个类型，它背后是数据库对“真实世界”的妥协——与其让人工补丁，不如一开始就锁死精度。
用 numeric 的时候，最常遇到的问题是“定义精度”的纠结。很多人上来就设 numeric(18,2)，觉得通用，结果存个超大额交易——比如几十亿——时发现位数不够。其实，numeric 的精度和标度是两回事：精度是总位数，标度是小数位数。比如 numeric(5,3)，最大能存 99.999，但整数部分只有 2 位，你硬塞 100，数据库会直接报错。我见过一个案例，某电商系统初期设计时，价格字段用了 numeric(10,2)，后来搞促销，折扣后价格变成 0.01，没问题。但某天用户买了个 99.99 的商品，结果插入失败，因为整数部分超了。后来改成 numeric(18,2)，才化解危机。这提醒我们，定义 numeric 时，最好提前评估数据范围。比如金融系统，金额可能上亿，就设 numeric(20,4)，留足余量；如果是科学计算，小数位可能多，就设 numeric(30,10)。别怕浪费存储，numeric 在底层是变长存储，你定义得宽，它只占实际需要的空间，但精度范围必须够用。
实际操作中，numeric 的加减乘除也暗藏玄机。比如在 PostgreSQL 里，用两个 numeric(10,2) 相乘，结果会自动变成 numeric(20,4)，因为数据库会扩展精度。但如果用 numeric 和整数相乘，比如 numeric(10,2) 乘以 2，结果仍是 numeric(10,2)，不会自动扩展。别小看这点差异，我曾在一个报表系统里踩过坑：销售数据用 numeric 存，计算折扣时乘以 0.9，结果小数位多了几位，但因为没有显式转换，最终汇总时精度丢失。后来改写成 column 0.9::numeric，强制指定类型，才保住精度。除法更是重灾区。两个 integer 相除可能被截断，但换成 numeric 就能保留小数。比如 7 除以 3，用 integer 得 2，用 numeric(10,4) 得 2.33。这个特性在计算平均值、税率时尤其重要。所以，写 SQL 时，只要涉及除法或乘法，最好把操作数都转成 numeric，或者直接定义字段为 numeric，省得后期找 bug 到头秃。
说到性能，numeric 和浮点数（float、double）的差距，就像手动挡和自动挡。numeric 计算时，数据库要做更多工作：拆解数字位、处理进位、保持精度，所以速度会慢一些。我做过一个压力测试，在百万级数据表上，用 numeric 求和比用 float 慢约 30%。但别慌，对于大多数业务系统，这点延迟可以忽略不计。真正让人难受的是索引和排序。numeric 字段上建索引，性能通常不如 integer 或 bigint，比较时涉及更复杂的逻辑。比如 WHERE price > 100.5，数据库需要逐位比较，不像整数那样一步到位。不过，现代数据库在不断优化，PostgreSQL 14 以后，numeric 的排序性能提升了约 15%。如果你追求极致性能，可以考虑把 numeric 拆成两个字段：整数部分用 bigint，小数部分用 smallint，然后组合查询。但这样会牺牲代码可读性，属于“杀鸡用牛刀”。我的建议是：业务优先，除非确认 numeric 成了瓶颈，否则别过早优化。
跨数据库迁移时，numeric 的兼容性是个大坑。比如 MySQL 里，numeric 和 decimal 是同一个东西，但 Oracle 里，numeric 其实是 number 的别名，精度范围更宽。我有个朋友从 SQL Server 迁移到 PostgreSQL，发现原来用 numeric(18,2) 存的金额，迁移后小数位被截断，因为 PostgreSQL 对精度处理更严格。查了半天，原来是 SQL Server 允许隐式截断，而 PostgreSQL 会报错。解决办法是迁移前统一修改字段定义，例如都设成 numeric(20,4)。更坑的是，某些数据库对 numeric 的默认精度不同。SQLite 的 numeric 实际上是浮点数，存进去的 99.99 可能变成 99.99001。于是，如果你在 SQLite 做测试，再部署到生产环境的 PostgreSQL，一定要重新测试边界值。我建议项目初期就确定好数据库类型，然后统一使用 decimal 关键字（大多数数据库都支持），避免后期踩坑。
说点高级玩法。numeric 不光能存数字，还能玩“数学运算”的花活。比如在 PostgreSQL 里，你可以用 numeric 生成序列号： 返回的是 bigint，但可以写成 把它转成 numeric，随后参与计算。numeric 还支持取模运算，例如 numeric(10,2) % 3，能精确得到余数。这在分账、拆分订单时特别有用。比如总金额 100.00 元，分给 3 个人，每人 33.33 元，余下 0.01 元。用 numeric 计算， 得到 33.333…，取整后再用 ，得到 0.01，完美解决。numeric 同样支持聚合函数，如 sum、avg，结果会自动保留精度。你甚至可以把数字转成文本拼接成发票号。但别用 numeric 做“伪随机数”，因为它的精确计算特性不适合模拟随机行为。numeric 是个“老实人”，你给它什么规则，它就怎么执行，适合“一分钱不能差”的场景。下次设计数据库时，记得把金额、税率、百分比这些字段都贴上 numeric 标签，它能帮你省掉无数个深夜修 bug 的时光。
