PostgreSQL舍入误差问题：差值之和与和值之差结果不相等

处理精度为3位小数的数值计算时，发现以下两个公式结果存在显著差异：

result_column_1 = SUM(column1) - SUM(column2)
result_column_2 = SUM(column1-column2)

数据集含近2050条记录，column1和column2已被截断（非四舍五入）至3位小数，尝试过ROUND()、转换为Decimal/Numeric、TRUNC()方法均无法解决。

核心原因：浮点数二进制存储的精度累积误差 #

虽然数据被截断到3位十进制小数，但如果存储类型是float或double这类浮点数，计算机无法精确表示所有十进制小数（比如0.1在二进制中是无限循环小数）。截断操作只是表面取3位，底层存储的数值仍带有微小的精度误差。

两个公式的误差累积逻辑不同：

• SUM(column1) - SUM(column2)：先分别累加两列的所有值，每列的精度误差会各自累积放大，最后相减时误差叠加
• SUM(column1-column2)：先逐行计算差值，每行的误差是两个值的误差之差，再累加这些差值，误差的累积路径不同，最终结果和前者产生显著差异

为什么ROUND/TRUNC/事后转Decimal没用？ #

这些操作仅对单个数值做表面处理，但如果原始数据是浮点数存储，截断/四舍五入后再存回浮点数，依然无法消除二进制存储的精度损失。事后转换为Decimal时，浮点数的误差已经存在，转换后也无法还原精确的原始十进制值。

解决办法 #

1. 改用定点数类型存储数据
   直接将column1和column2的存储类型改为DECIMAL(precision, 3)或NUMERIC(precision, 3)（precision根据数值范围调整，比如10），确保每个值都是精确的十进制3位小数，从根源避免浮点数误差。注意要在数据入库时就使用该类型，不要事后转换。

2. 整数运算规避浮点数误差
   如果无法修改存储类型，将数值放大1000倍转换为整数，用整数运算完成求和，最后再缩小回原精度：

   -- 对应result_column_1的整数运算版本
   result_column_1 = (SUM(CAST(column1 * 1000 AS INT)) - SUM(CAST(column2 * 1000 AS INT))) / 1000.0
   -- 对应result_column_2的整数运算版本
   result_column_2 = SUM(CAST((column1 - column2) * 1000 AS INT)) / 1000.0
   

   整数运算不存在精度损失，两个公式的结果会完全一致。

3. 验证数据的实际精度
   检查每一行的column1和column2是否确实是精确的3位十进制数，比如用格式化函数查看：

   SELECT column1, FORMAT(column1, 'N3'), column2, FORMAT(column2, 'N3') FROM your_table
   

   如果格式化后的值和原始值不一致，说明数据底层仍有隐藏精度，需要先清洗数据为精确的3位小数。

内容的提问来源于stack exchange，提问作者Adi