PostgreSQL中附件大小与BLOB存储大小存在差异的原因咨询

17MB TIFF存储后变为22MB对应的膨胀比例约30%，和PostgreSQL二进制存储的常见额外开销特征完全匹配，按出现概率从高到低，原因如下：

• 最高概率：应用层写入时做了Base64编码
  很多开发者在写入二进制数据时，没有使用数据库驱动提供的原生二进制参数绑定能力，而是手动将文件字节流转为Base64字符串拼接SQL写入。Base64编码的固定膨胀率为33%（每3字节原始数据转为4字节ASCII字符），和给出的17MB转22MB的比例完全吻合。这种场景下差值绝对值随文件大小线性增长，如果不同文件类型走了不同的编码/序列化逻辑，膨胀比例也会出现差异，和描述的现象完全一致。
• Large Object存储的固有元组开销
  如果使用PostgreSQL原生Large Object机制（通过lo_*系列接口操作，数据存在pg_largeobject系统表），大对象会被拆为固定大小的块（默认块大小LOBLKSIZE为2KB）存储，每个块对应表中的一行元组，单条元组需要携带约24字节的事务可见性标识、行头、字段偏移等元数据，再叠加数据页页头、页内碎片的开销，整体会产生10%~30%的额外空间占用，文件越大累计开销越高。
• 统计口径包含非内容空间
  如果是通过数据库表空间统计函数（比如pg_total_relation_size）计算BLOB大小，得到的数值会包含TOAST表、TOAST索引、MVCC机制产生的dead tuple（未清理的旧版本数据）的占用空间，会比BLOB本身的实际内容大很多，尤其是BLOB字段刚经历过更新、还没触发VACUUM清理时，差值会更明显。
• 应用层自动附加元数据
  部分ORM框架、文件存储组件在写入二进制字段时，会自动在内容前拼接封装头，存储文件哈希、类型标识、上传时间等额外信息，也会带来一定体积增量，不同文件类型触发的封装逻辑不同时，增量大小也会变化。

• 从数据库中取出对应BLOB的前10个字节查看，如果内容是可打印ASCII字符，且TIFF文件对应BLOB开头为TU0/SUk、JPG文件对应开头为/9j/，即可确认是Base64编码问题，改为驱动原生二进制参数写入即可解决。
• 对Large Object类型，执行SELECT sum(octet_length(data)) FROM pg_largeobject WHERE loid = [目标大对象OID];统计实际内容长度，如果该值和原文件大小一致，说明之前的统计值包含了索引、垃圾数据等非内容空间。
• 对bytea类型字段，执行SELECT octet_length(blob字段名) FROM 业务表 WHERE 记录ID = [目标记录ID];查看实际内容长度，如果该值就比原文件大30%以上，优先排查应用层的序列化、编码逻辑。

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