数值计算是数据库应用中绕不开的话题，无论是电商系统的订单金额汇总，还是报表系统的统计聚合，都离不开数学函数的支持。PostgreSQL提供了一套完善的数值类型体系和丰富的数学函数库，但如果对类型特性和函数行为理解不深，很容易踩到精度丢失、隐式类型转换、四舍五入结果不符合预期等坑。本文将从数值类型选型入手，详细介绍常用数学函数的用法，并结合实际业务场景演示如何组合运用这些函数。
一、先搞清楚数值类型：选对类型是准确计算的前提
PostgreSQL的数值类型主要分为四大类：整数类型（smallint、integer、bigint）、精确小数类型（numeric、decimal）、浮点类型（real、double precision）以及序列类型（serial、bigserial）。很多精度问题的根源不在函数，而在于类型选错了。
numeric是精确存储的任意精度类型，可以指定精度和标度，例如numeric(10,2)表示总共10位数字，其中小数占2位。涉及金额的字段，强烈建议使用numeric而不是浮点类型。浮点类型采用二进制存储，像0.1这样的十进制小数在二进制中是无限循环的，存储时必然产生误差。你可以直接执行下面的SQL验证一下：
SELECT 0.1::float8 + 0.2::float8 AS float_result,
0.1::numeric + 0.2::numeric AS numeric_result;
-- float_result : 0.30000000000000004
-- numeric_result: 0.3
这就是经典的浮点误差问题。在财务、计费等对精度敏感的场景中，一个看似微小的误差经过成千上万次累加后，最终可能造成对账不平。整数类型的选择也要注意范围：integer最大约21亿，如果主键自增速度较快或者需要存放大数值，应该直接用bigint，避免溢出报错。
二、取整与舍入函数：round、trunc、ceil、floor详解
取整类函数是使用频率最高的数学函数，但细节容易被忽视。round(numeric, int)对数值进行四舍五入，第二个参数指定保留的小数位数，可以传负数对小数点左侧的整数部分舍入，例如round(1234.567, -2)返回1200。需要注意的是，round只接受numeric类型的参数，如果传入浮点数会直接报错：
SELECT round(123.4567, 2); -- 123.46 SELECT round(123.4567::float8, 2); -- 报错：函数 round(double precision, integer) 不存在 -- 正确做法：先转成numeric SELECT round(123.4567::float8::numeric, 2); -- 123.46 SELECT round(1567.89, -2); -- 1600
trunc是直接截断，不做四舍五入，trunc(123.4567, 2)返回123.45。它和floor的区别在于floor只向负无穷方向取整且不保留小数位，floor(123.99)返回123，而floor(-123.01)返回-124。ceil（也可写作ceiling）则向正无穷方向取整。这四个函数在业务中的分工是：金额展示用round，用量统计用trunc，分页计算总页数用ceil，区间下界计算用floor。
另外要提醒一点，PostgreSQL的numeric四舍五入采用的是标准规则，即"四舍六入五成双"附近的处理可能和你预期的银行家舍入法有差异，如果业务对舍入规则有严格要求，需要仔细测试边界值，必要时用自定义函数实现。
三、常用数学函数与聚合计算实战
除了取整，PostgreSQL还内置了abs（绝对值）、mod（取模）、power（幂运算）、sqrt（平方根）、exp（指数）、ln和log（对数）、pi()（圆周率）、三角函数以及random()（生成0到1之间的随机数）等函数。div函数做整数除法并返回整数商，mod返回余数，两者配合可以完成按桶分组的计算。
SELECT abs(-15.5) AS 绝对值, -- 15.5
mod(17, 5) AS 取模, -- 2
div(17, 5) AS 整除商, -- 3
power(2, 10) AS 幂运算, -- 1024
sqrt(144) AS 平方根, -- 12
floor(random()*100) AS 随机整数; -- 0到99的随机整数
在实际业务中，数学函数经常和聚合函数配合使用。举个例子，一张订单表需要统计每个用户的消费总额、平均单额并保留两位小数，同时计算消费排名，可以这样写：
SELECT user_id,
round(sum(amount)::numeric, 2) AS total_amount,
round(avg(amount)::numeric, 2) AS avg_amount,
ceil(count(*) / 10.0) AS approx_pages
FROM orders
GROUP BY user_id
ORDER BY total_amount DESC;
注意这里对sum和avg的结果做了显式转换再round，因为对整型列求和返回的是整数或长整数，对浮点列求平均返回浮点，直接调用双参数round都可能出错，养成显式转换的习惯能省去不少排查时间。分页计算中的总页数也是同理，count(*)除以每页条数要用ceil向上取整，并且保证除数写成10.0这样的浮点或numeric形式，否则整数除整数会被截断小数部分，导致总页数偏少。
四、容易踩的坑与最佳实践总结
第一个坑是隐式类型转换。PostgreSQL在numeric和float之间不会自动做你期望的转换，很多函数只提供numeric重载，遇到类型不匹配会直接报"函数不存在"的错误，错误信息里会列出完整的函数签名，看懂签名就能快速定位是类型问题。第二个坑是字符串参与运算，例如'123.45' + 1在PostgreSQL中是不允许的，必须先转换类型：加号没有字符串的重载版本，这一点和MySQL的行为不同，从MySQL迁移过来的代码要格外注意。
-- 字符串转数值的推荐写法
SELECT '123.45'::numeric + 1; -- 124.45
SELECT cast('123.45' AS numeric) * 2; -- 246.90
第三个坑是random()函数的结果不可复现，如果需要可重复的随机序列，可以先用setseed()设置种子。做随机排序取样的场景下，ORDER BY random()虽然简单，但大表上性能很差，因为它需要对全表排序，更好的方案是结合主键范围随机生成采样点。
总结几条实践建议：金额和需要精确计算的数值一律使用numeric并明确标度；调用取整和舍入函数时显式转换参数类型；分页和分组计算注意整数除法的截断问题；编写统计SQL时先用小的边界数据验证round、trunc的行为是否符合预期。掌握这些数学函数的原理和细节之后，大部分数值计算都可以直接交给数据库完成，既减少了应用层的代码量，也保证了计算结果的一致性。
PostgreSQL数学函数数值计算修改时间：2026-09-13 13:14:41