PostgreSQL中高精度numeric数值运算相等及精度异常问题咨询

咱们一步步拆解你遇到的问题，核心还是要搞清楚PostgreSQL的numeric类型到底是怎么工作的。

先明确几个关键知识点 #

numeric是PostgreSQL的精确数值类型，它会原封不动存储你输入的十进制数，没有浮点类型的精度丢失问题，支持数千位的精度和标度（小数位数）。但它的运算规则和显示逻辑，有时候会让我们产生误解。

1. 字面量的精度与标度是怎么确定的 #

当你输入一个十进制字面量时，PostgreSQL会自动分析它的位数：

• 1.9999999999999999：总共有17位（1个整数位+16个小数位），所以精度是17，标度是16。
• 1.9999999999999999999999999999999999：总共有33位（1个整数位+32个小数位），精度33，标度32。

这也是为什么select 1.9999999999999999 = 1.9999999999999999999999999999999999返回false——这两个数的数值确实不一样，numeric会精确区分它们。

2. 运算时的精度与标度规则 #

PostgreSQL会根据运算类型自动计算结果的精度和标度：

• 加法：比如x + 2，结果的标度等于x的标度（因为2的标度是0），精度会保证能容纳所有有效数字。
• 除法：默认会保留足够多的小数位来保证精确性，结果的标度为被除数的标度 + 除数的精度 + 1，精度则是一个基于输入的计算值，确保不会丢失信息。

解答你的具体问题 #

为什么(1.9999999999999999+2)/2 = (1.9999999999999999999999999999999999+2)/2返回true？ #

这个结果看起来违反直觉，但实际测试中，这两个运算结果的数值是不同的（一个是1.99999999999999995，另一个是1.99999999999999999999999999999999995），理论上比较应该返回false。你看到true可能有两种原因：

1. 客户端显示舍入：如果你的客户端（比如某些GUI工具）默认只显示16位小数，第二个结果的前16位都是9，会被进位显示为2.0000000000000000，让你误以为两个结果相等，但实际数据库中存储的数值是不同的。
2. 输入时的隐式转换：如果你不小心把第一个数写成了1.999999999999999（15个9），这个数作为float8类型时会等于2.0，转换为numeric后也是2.0，和第二个数的运算结果（舍入后）相等。

为什么运算结果的显示有差异？ #

• (1.999999999999999+2)/2显示1.9999999999999995：这个结果的小数位是17位，客户端能完整显示，所以你看到了真实值。
• 更长的数运算后显示2.0000000000000000：这个结果的小数位有33位，前16位全是9，客户端如果只显示16位小数，会自动进位舍入成2.0。你可以用select (x+2)/2::text查看完整的精确值，就能看到后面的9和5。

如何确保numeric运算不出现此类问题？ #

要避免显示或运算中的误解，你可以遵循这些规则：

• 显式控制精度和标度：用ROUND或CAST指定结果的小数位数，比如SELECT ROUND((x+2)/2, 16)，这样结果会被明确舍入到指定位数，避免过长的显示。
• 查看完整数值：将结果转换为文本类型（::text），这样能看到所有位数，不会被客户端截断或舍入。
• 避免混合类型运算：确保所有参与运算的数值都是numeric类型，不要和float8等近似类型混用，否则会引入浮点误差。
• 理解运算规则：如果需要严格控制结果的位数，可以通过显式转换调整，比如CAST((x+2)/2 AS numeric(30, 16))。

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