先说明一下，这篇文章不是给你讲“numeric怎么存进内存”这种教科书定义，而是把我在实际项目里和 PostgreSQL 的 numeric 搏斗过几轮之后，积累下来的完整链路梳理。从数据库磁盘上的存储格式，到进程内存里的表示，再到客户端 Java/Python 读进来的对象形态，一次讲透。
如果你正好在处理这类问题：PG 导出数据后出现精度丢失、numeric 字段在 Java 里变成科学计数法、或者批量读取 numeric 时内存飙高，那这篇文章基本就是照着你的痛点写的。
1. 先说清楚：这个问题到底在问什么
1.1 从一张报错截图说起
前阵子有个同事跑数据同步，源端 PG 表里有个字段是numeric(18, 4)，他拿 JDBC 读出来以后直接doubleValue()转成 Double 再塞进目标库。跑完一看，几千万金额对不上账，小数点后面第二位就开始飘。
这其实是所有跟 numeric 打过交道的人都会遇到的经典问题：numeric 不是浮点数，它是一套精心设计的十进制变长编码。如果你不知道它在不同环节的表示方式，就很容易在“数据库存的值”和“应用内存里的值”之间被精度坑一下。
所以这里讲的“PG库数据numeric格式数据读到内存中格式”，本质上是三条链路：
- 磁盘上的存储格式（tuple 里的 varlena 字节序列）
- PostgreSQL 进程内存里的datum / NumericVar 结构
- 应用客户端内存里接收到的对象格式（Java BigDecimal、Python Decimal 等）
三者形态完全不同，但很多资料把它们混在一起讲，导致新手以为 numeric 在内存里就是字符串，或者就是 BigDecimal，其实都不准确。
1.2 为什么 numeric 比 float 更值得认真对待
PostgreSQL 里浮点类型（float4/float8）用的是 IEEE 754 二进制表示，快，但存 0.1 这种十进制小数会有无限循环二进制尾巴，只是显示层截断了。numeric 则完全绕开二进制浮点，直接用十进制的“数字数组”来存，所以它能精确表示所有十进制小数。
代价是：慢、占空间、结构复杂。
一个numeric(18,4)表面上只占 9 字节左右（整数+小数位都能装下），实际上因为要存符号、小数位、每组四位十进制数，它的磁盘占用和内存开销会比 float8 高不少。更重要的是，它在内存里也不是一个 64 位的数，而是一个结构体加一组 int16 数组。
理解了这一点，你就知道为什么很多 PG 内核开发者建议：能用整数搞定的事，别轻易上 numeric。但业务里金额、税率、汇率这种必须精确保存的字段，又绕不开它。所以搞懂它的内存格式不是闲得没事，是真能救命的知识点。
2. 磁盘与网络上的 numeric：那套古老的十进制打包格式
2.1 base 10000：numeric 真正的“数字单元”
很多人第一次看 PG 源码里的 numeric 相关注释都会懵：为什么好好的二进制不用，要用 10000 做基数？
先看源码里最核心的注释（src/backend/utils/adt/numeric.c）：
/* * Numeric data is stored in decimal digits, with base 10000. * ... * The value represented by the digit array is * sign * 0.digits[0] * 10000^weight + ... */这里 base 10000 的意思是：每四位十进制数打包成一个 int16。比如12345678.90，会被拆成：
123456789000
对应的 weight 是 1（因为1234 * 10000^1才是最高位的量级），dscale 是 2（保留两位小数）。所以这个数值在 PG 内部不是“一个数”，而是[1234, 5678, 9000]三个 int16 元素加一堆元数据。
为什么用 10000 而不是 10？用 10000 可以把四位十进制压进一个 16 位整数，既保留了十进制精确性，又比逐位存储节省空间。为什么不直接上更大的基数比如 10^9？因为 int16 的符号范围是 -32768 到 32767，四位十进制数最大 9999，落在安全区间内，做乘法运算时不容易溢出。如果换 10^9 就得用 int32，中间运算还要防溢出，麻烦得多。这是 PostgreSQL 在“精度”和“运算效率”之间做出的老练取舍。
2.2 存储布局逐个字节拆
在磁盘的元组里，numeric 是变长类型，走了 varlena 那一套。完整布局如下：
typedef struct NumericData { int32 vl_len_; /* varlena header */ int16 n_weight; /* weight of first digit */ uint16 n_sign; /* sign (see NUMERIC_SIGN_*) */ int16 n_dscale; /* display scale */ int16 n_data[FLEXIBLE_ARRAY_MEMBER]; /* decimal digits */ } NumericData;逐个字段解释一下：
vl_len_：变长头，4 字节。如果数值很短，PG 还会用 1 字节的短 varlena 头做压缩，这是很多人在内存分析时漏掉的一个细节。n_weight：第一个 digit 的权重，也就是10000^weight的指数。比如12345678.90的 weight 是 1。n_sign：符号位。不是简单的 0/1，而是按位掩码设计：0x0000= 正数0x4000= 负数0xC000= NaN0xD000= 正无穷0xF000= 负无穷
n_dscale：显示小数位，也就是用户用numeric(10,2)指定的那个 2，或者运算后保留的小数位。n_data[]：实际数字数组，每个元素是一个 0 到 9999 的 int16。
举个例子，12345678.90的存储字节序列大致是：
header(4B) | weight=1(2B) | sign=0(2B) | dscale=2(2B) | 1234(2B) | 5678(2B) | 9000(2B)总共 4 + 2 + 2 + 2 + 2 + 2 + 2 = 16 字节（没算短头部优化的情况）。而float8才 8 字节。这就是为什么我在 1.2 里说它又慢又占地方——真实对比下来，numeric 的存储开销通常是 float8 的两倍起步，数据量一大，内存和磁盘压力都会上来。
顺带提一句：PostgreSQL 15 之前 numeric 的小数位最多 16383，整体精度上限是 131072 位？准确说 PG15 前精度上限是 1000 位，PG15 把数值上限扩展到了numeric最大精度 131072 位、最大小数位 16383。但这个改动没有动存储格式，只是放宽了 dscale 和 digit 数量的限制。
2.3 浮点转 numeric 的精度陷阱
在 PG 里执行numeric '0.1'和0.1::float8::numeric，结果看起来一样，但内部字节完全不一样。
前者从字符串解析，直接把 “1” 放进 digit 数组，精确无误差。后者是先转成 IEEE 754 的二进制浮点，再把这个二进制近似值转成十进制 digit，得到的是0.1000000000000000055511151231257827021181583404541015625这种一长串尾巴。
这个问题在应用层同样存在。你用rs.getBigDecimal()没问题，但如果手贱调了getDouble()再BigDecimal.valueOf(d)，精度就废了。后面实操部分我再细讲。
3. 读进内存之后：几种“内存格式”要分清
3.1 PostgreSQL 进程内的 datum 与 NumericVar
当 PG 执行查询、把 numeric 字段读进进程内存时，它首先拿到的是上面说的那个NumericData指针，也就是一个 varlena datum。
要注意：这个 datum 不是直接用于计算的。因为 packed 格式的 digit 数组是按四位十进制打包的，做加减乘除时进位借位很麻烦。所以 PG 在执行运算前会把它“展开”成NumericVar：
typedef struct NumericVar { int ndigits; /* number of digits in digits[] */ int weight; /* weight of first digit */ int sign; /* NUMERIC_POS, NUMERIC_NEG, etc */ int dscale; /* display scale */ NumericDigit *buf; /* allocated buffer */ NumericDigit *digits; /* decimal digits */ } NumericVar;这里的NumericDigit其实还是 int16，但digits[]是连续分配的一段内存。执行SELECT col + 1这类操作时，PG 会把 datum 转成 NumericVar，算完再转回 NumericData 存盘或发往客户端。
所以“读进内存的格式”严格来说有两层：
- 原始 datum：只读快，适合直接输出、序列化
- NumericVar：可计算，但占用更多内存（因为 buf 是可变的，通常会按最大精度先分配一段缓冲区）
如果你在做 PG 内核开发或者 C 扩展，这两者必须分清。如果你只是用 JDBC 读数据，那上面这些属于“知道有这回事就好”，重点是下面这一层。
3.2 客户端 Java 内存中的表现
Java 这边，JDBC 驱动拿到 PG 返回的数据后，会根据协议决定给你什么对象。
PostgreSQL JDBC 驱动默认走文本协议（除非你设置了prepareThreshold触发了二进制协议）。文本协议下，numeric 传回来的就是一个字符串，比如"12345.6700"。PGJDBC 拿到这个字符串后，如果你调getBigDecimal()，它就用new BigDecimal(String)准确构造一个java.math.BigDecimal对象。
重点来：在 Java 内存里，numeric 最终几乎总是表现为 BigDecimal。BigDecimal 内部的结构是：
final int[] intCompact; // 紧凑表示 final int precision; // 有效数字个数 final int scale; // 小数位它同样是“十进制 digit 数组”的思想，跟 PG 的 base 10000 异曲同工，只是 Java 直接用了 int 数组。所以 numeric -> BigDecimal 是精度无损的天然映射。
但有一个非常隐蔽的 FAQ：如果你调的是getObject()，某些旧版本 PGJDBC 会返回PGobject，而PGobject.getValue()返回的是字符串。看起来差不多，但如果你直接把这个字符串当“内存里的 numeric”，后续做 JSON 序列化时可能被转成字符串而不是数字。我之前就见过一个接口，别人拿PGobject的字符串塞进 JSON，结果前端拿到的是"12345.67"带引号的字符串，前端求和时变成字符串拼接，直接炸了。
3.3 二进制协议里的 numeric（送进网络前的形态）
如果客户端和 PG 之间走了二进制协议（比如 PGJDBC 的binaryTransfer），numeric 在网络上的载荷格式是：
int16 ndigits int16 weight uint16 sign int16 dscale int16 digits[ndigits]这个格式和磁盘上的NumericData几乎一样，只少了 varlena 头。PGJDBC 在 42.x 版本里对 numeric 的二进制解析支持一直不算完善，很多版本遇到非默认 scale 的 numeric 时，干脆退回文本协议。所以你现在用 JDBC 连 PG，绝大多数场景下驱动都是走文本协议返回字符串，再由驱动解析成 BigDecimal。
这里我想强调一个容易踩的坑：如果你自己写网络协议层去接 PG 的二进制 numeric，别想当然按 float 的字节序解析。必须按上面那个顺序：先读 ndigits，再读 weight/sign/dscale，最后读 digits 数组。字节序是网络序（大端），digits 每个元素是带符号的 int16 还是无符号？严格说 digit 本身按无符号处理，但 weight/sign 都是带符号的，sign 是 uint16。我在做数据同步工具时踩过这个坑，按小端解析了 weight，结果所有大数的量级全部错乱，查了半天才发现协议里 int16 是大端。
4. 实操：从 PG 到应用内存的完整链路
4.1 用 JDBC 把 numeric 接进 Java 内存
最常见的场景就是 Java 服务查 PG，把 numeric 读进内存。直接给一套标准写法：
try (PreparedStatement ps = conn.prepareStatement( "SELECT id, amount, tax_rate FROM orders WHERE id = ?")) { ps.setLong(1, orderId); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { long id = rs.getLong("id"); BigDecimal amount = rs.getBigDecimal("amount"); BigDecimal taxRate = rs.getBigDecimal("tax_rate"); // 不要这么干： // double amountDouble = rs.getDouble("amount"); } } }几个经验点：
优先用
getBigDecimal()，别用getDouble()。getDouble()内部做了Double.parseDouble(rs.getString())或二进制转换，一旦 numeric 的小数位超过 double 的精确范围（大约 15-17 位有效数字），精度就丢了。金额字段丢精度，对账必挂。如果需要数值运算，直接用 BigDecimal 的方法，比如
amount.multiply(taxRate).setScale(4, RoundingMode.HALF_UP)。不要转成 Double 算完再转回 BigDecimal，这是很多“线上金额差一分钱”事故的根源。setScale 的时机要后置。PG 返回的 dscale 可能是 2，但中间运算结果的小数位会变长。你可以在最终落库或返回前端前统一 setScale，中间环节保精度。
大量读取时的内存优化。BigDecimal 对象比较重，每个对象有 intCompact、精度、scale 等字段，加上对象头，一个小数可能占 40-80 字节。如果你一次查 10 万行 numeric，那就是几 MB 到十几 MB 的内存。如果只是展示，直接用字符串反而更省；如果要做 map/reduce 聚合，可以用
BigDecimal但尽量避免中间产生大量中间态对象。
JDBC 还有一个隐藏机制：setFetchSize()。PG 默认会把查询结果全部缓冲到客户端内存，对于大结果集，必须手动setFetchSize(1000)或setFetchSize(ResultSet.TYPE_FORWARD_ONLY)配CONCUR_READ_ONLY才能走游标模式，逐批拉取。否则一次读 500 万行 numeric，JVM 内存直接给你颜色看。这个跟 numeric 本身关系不大，但跟“读到内存”的体量强相关，我后面排查部分还会提。
4.2 高性能场景：如何减少转换开销
如果你是在做数据同步、ETL、导入导出这种需要把大量 numeric 从 PG 读出来再写走的任务，那么“读到内存”这一步的代价就很肉疼了。
我实测过一个场景：单表 2000 万行、8 个 numeric 字段，用 JDBC 默认方式全量读，JVM 老年代涨了接近 2GB，GC 频繁。后来做了三件事，内存直接降了一个量级：
改用流式读取：
stmt.setFetchSize(5000)，让 PG 分批次返回，不要一股脑塞进 ResultSet 缓冲区。能少建对象就少建：如果目标端也是 PG，读出来直接用
COPY的文本格式流式转发，numeric 就用字符串传递，不转 BigDecimal。字符串是 immutable 的，生命周期短，GC 压力小很多。关闭二进制传输（如果你显式开过）：
prepareThreshold=-1或直接不设置，让驱动走文本协议，省去二进制解析逻辑的开销。这不是绝对真理，但 numeric 的二进制解析在 PGJDBC 里效率并不高，文本协议加字符串切割反而更稳。
下面是流式读取的参考写法：
try (Connection conn = dataSource.getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps = conn.prepareStatement( "SELECT id, amount FROM big_table", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)) { ps.setFetchSize(1000); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { long id = rs.getLong("id"); BigDecimal amount = rs.getBigDecimal("amount"); // 消费，处理，写入下游... } } } conn.commit(); }注意TYPE_FORWARD_ONLY和CONCUR_READ_ONLY缺一不可，否则 PGJDBC 不会启用服务端游标，fetchSize 直接失效。
4.3 Python / C 侧验证
除了 Java，Python 这边读 PG 的 numeric 也是同理。psycopg2默认会把 numeric 映射成decimal.Decimal，这是无损的。
import psycopg2 import psycopg2.extras conn = psycopg2.connect("dbname=test user=postgres") cur = conn.cursor() cur.execute("SELECT 12345678.90::numeric(18,2)") row = cur.fetchone() print(type(row[0])) # <class 'decimal.Decimal'> print(row[0]) # 12345678.90但有一个容易忽略的点：如果你用的是psycopg2.extras.RealDictCursor等自定义游标，或者某些 ORM 的默认类型映射没注册 Decimal，numeric 可能被映射成str。SQLAlchemy + psycopg2 的经典组合一般没问题，但如果你用的是pg8000或者手写协议库，注意看一下类型映射，别让数字变字符串又变回来，精度和类型都会出幺蛾子。
C 客户端（libpq）这边更原始：PQgetvalue 返回的就是字符串指针，内存里就是char[]，需要你自己解析成long long或者任意精度库。这也是为什么“内存格式”在不同语言里差别这么大——本质上 PG 给到客户端的，不管文本还是二进制，最终都需要客户端解析一次，而解析出来的对象形态完全取决于语言和驱动。
5. 常见问题与排查实录
5.1 经典事故：numeric 变成科学计数法
现象：Java 里读 numeric，然后 JSON 序列化返回前端，前端显示1.2345678E7，或者莫名其妙变成"1.23E7"字符串。
原因：numeric 读成 BigDecimal 后，如果调用了BigDecimal.toString()，当数值绝对值大于等于 1E+7 或小于 1E-3 时，Java 会用科学计数法表示。某些 JSON 库（比如比较老的 fastjson 版本）会直接调用 toString，于是数字就变成科学计数法了。
排查和解决：
BigDecimal amount = rs.getBigDecimal("amount"); // 想要普通十进制字符串： String plain = amount.toPlainString();同时，序列化时可以用@JsonFormat(pattern = "0.########")之类的注解，或者自定义序列化器，保证 BigDecimal 输出为普通数字格式。这个坑特别常见，因为 PG 里很正常的12345678.90，到了 Java 里 toString 就成了1.234567890E+7，前端看到直接懵。
5.2 内存暴涨：numeric 是否被误存成 text
有一类内存问题是 schema 设计挖的坑：应用层为了省事，把金额字段直接定义成text或varchar，写入时String.valueOf(amount)，读出来再new BigDecimal(str)。
这种做法的内存代价非常阴险：
- text 在 PG 进程里是 varlena，按字节存，占的空间可能比 numeric 还大。
- 到了 Java 内存里，它是 String（包含 char[]，UTF-16，一个数字字符占 2 字节），再转 BigDecimal 又要创建第二个对象。你等于一份数据占了 double 的内存。
- 更麻烦的是，text 无法保证“数值格式统一”，同一个值可能存出
1.23、1.230、01.23三种形态，读出来再转 BigDecimal 时，scale 不一致，直接导致对账不平。
所以排查内存问题时要先看 schema：information_schema.columns里查一下，如果金额字段是character varying，那问题根源就是设计错了，改成 numeric 不仅是省内存，更是保正确。
5.3 排序、分组、去重中 numeric 的隐藏成本
numeric 的排序和比较不是 CPU 一条指令能搞定的，它要走numeric_cmp函数，逐个 digit 比较。比 int8 的排序慢一到两个数量级。在 GROUP BY 或 DISTINCT 时，PG 要拿 numeric 做 hash，而 numeric 没有天然的 int hash，得先转成一种规范化表示再算，这里也有不小的开销。
我之前排查过一个慢查询：一张 5 亿行的流水表，按account_id, amount做去重，amount 是 numeric(18,2)。去重跑了 40 分钟，把 amount 改成 bigint（金额*100，用分存储）后，只跑了 6 分钟。除了算法和索引的影响，数据类型带来的比较成本真的不可忽视。
这里给个建议：能用整数表达精确金额的地方，优先用整数（int8 + 最小货币单位）。numeric 留给真正需要任意精度和小数位动态变化的场景。实在要用 numeric，尽量避免在高频 join/group by 的 key 上使用，哪怕是二级索引也会受影响。
5.4 快速排查工具
如果你怀疑数据或内存里有异常的 numeric，有几个小技巧：
-- 查看字段的数据类型 SELECT column_name, data_type, numeric_precision, numeric_scale FROM information_schema.columns WHERE table_name = 'your_table'; -- 找出非标准格式的 numeric（会报错或返回0） SELECT count(*) FROM your_table WHERE amount::text ~ '[^0-9.\-]';在 Java 侧，如果你怀疑getObject()返回的类型不对，可以打印一下：
Object v = rs.getObject("amount"); System.out.println(v.getClass().getName()); System.out.println(v);正常情况下应该是java.math.BigDecimal。如果出来的是org.postgresql.util.PGobject，检查一下驱动版本和连接参数。
6. 我踩过的几个坑
最后说几点个人体会，全是从线上事故里摔出来的。
第一个坑：不要相信getString()拿到的 numeric 字符串可以直接往文件里写。PG 输出的文本格式可能包含+号、指数形式（比如1e+20这种很大或很小的数值会以科学计数法输出？准确说 PG 的 numeric 文本输出在 scale 极大或极小时也会用指数形式），如果你做数据文件迁移，最好统一用numeric::text配合to_char()做格式化，或者直接用 COPY 导出。用 COPY 导出时，numeric 默认就是纯文本，分隔符注意转义即可，这个格式对大批量迁移非常友好。
第二个坑：批量写入 numeric 时，PreparedStatement 的 setBigDecimal 一定要带上 scale。ps.setBigDecimal(1, amount)有些驱动会把你 BigDecimal 的 scale 原样传过去，但有些老版本驱动要求手动ps.setBigDecimal(1, amount.setScale(2, RoundingMode.HALF_UP))，不然目标列是 numeric(10,2)，你写个 scale=0 的值进去会报数值溢出或者被静默截断。我在 Maven 里用了一个老版本的 PGJDBC，就吃过这个亏，批量 insert 几万条后才发现小数位全丢了。
第三个坑：JVM 内存调优时别只盯堆内。如果你用 JDBC 读大结果集，PGJDBC 在流式读取时会在堆外开 DirectByteBuffer，堆外内存堆满也会抛 OOM。用-XX:MaxDirectMemorySize限制一下，同时调小 fetchSize，能避免诡异崩溃。这和“numeric 读到内存”直接相关——numeric 本身对象重量大，流的批量缓冲又占堆外空间，两相叠加特别容易爆。
第四个坑：如果你在做 PG 扩展或者用 PL/pgSQL 处理 numeric，别直接用numeric类型做循环变量。循环一百万次精度计算，性能和内存都会让你崩溃。能先转成整数处理就转成整数，最后再转回 numeric。PL/pgSQL 里 numeric 的中间结果往往保留 16383 位小数，你压根不需要那么高精度，记得::numeric(18,4)手动收一下 scale，能省巨量内存。
总结成一句话就是：numeric 在 PG 里是一套“十进制四位一打包”的变长结构，到了内存里一定要用精确十进制对象去接，Java 用 BigDecimal，Python 用 Decimal，C 端自己换任意精度库。中间任何转成 float/double 的动作，都是在拿你的业务正确性开玩笑。如果你能把这套链路理清楚，后面再遇到“PG numeric 读到内存格式不对”这类问题，基本十分钟就能定位到是协议解析、驱动版本、类型映射还是代码转换的问题。
