如何在SQL存储过程中处理大型二进制对象（BLOB）？

Oracle需先占位再分段写BLOB，SQL Server推荐VARBINARY(MAX)直接赋值，MySQL几乎不支持存储过程安全操作BLOB，PostgreSQL需encode/decode BYTEA，跨库应弃用强类型参数改用VARCHAR2/TEXT。

直接在存储过程中操作 BLOB，绝大多数数据库都不支持“拿来就写”，必须走特定初始化 + 分段写入路径；Oracle 最规范，MySQL 基本不支持，SQL Server 和 PostgreSQL 也得绕开直接赋值。

Oracle 存储过程里写 BLOB 必须先占位再追加

直接 INSERT INTO t(blob_col) VALUES (:raw_data) 超过 32767 字节大概率报 ORA-22922: nonexistent LOB value。根本原因是没在事务上下文中创建可写的 LOB 句柄。

• 第一步：用 EMPTY_BLOB() 占位并 FOR UPDATE 锁定目标行
• 第二步：SELECT blob_col INTO :lob_var FROM t WHERE id = ? FOR UPDATE 获取句柄
• 第三步：调用 DBMS_LOB.WRITEAPPEND(lob_var, amount, buffer) 分段写，每次 buffer ≤ 32767 字节（VARCHAR2 上限）
• 临时 LOB 必须设 cache => TRUE，否则写完读不到；写完记得 DBMS_LOB.FREETEMPORARY，否则 PGA 内存泄漏

SQL Server 存储过程更新 VARBINARY(MAX) 很简单，但别碰 IMAGE

IMAGE 类型已废弃，不能用 LEN() 查长度，也不支持函数参与运算；新表一律用 VARBINARY(MAX)，它能直接传参、直接 UPDATE。

• 建表写 content VARBINARY(MAX)，不是 IMAGE
• 存储过程参数声明为 @data VARBINARY(MAX)，然后 UPDATE t SET content = @data WHERE id = @id 即可
• 插入前确认 max server memory 足够，否则大文件 INSERT 可能触发内存溢出
• 若 BLOB 平均超 2MB，启用 FILESTREAM，数据存在 NTFS 文件系统，数据库只存指针

MySQL 存储过程几乎没法安全操作 BLOB

MySQL 存储过程没有类似 DBMS_LOB 的包，也没有 FOR UPDATE 锁定 BLOB 字段的语义；SELECT ... INTO @var 会受 max_allowed_packet 限制（默认 4MB），超长就截断或报错。

• 不要在存储过程里拼接、截取、计算 BLOB —— CONCAT()、SUBSTRING() 都可能隐式转字符串导致乱码或截断
• 真要分片存，建辅助表 blob_chunks(table_id, chunk_no, data BINARY(64K))，用循环 INSERT 拆写
• 更推荐把读写逻辑移到应用层：Java 用 PreparedStatement.setBlob()，Python 用 cursor.execute(..., (binary_data,))
• 如果非得用 LOAD_FILE()，注意 MySQL 用户要有 FILE 权限，且文件必须在数据库服务器本地磁盘上

PostgreSQL 的 BYTEA 必须 encode/decode 才能入库

PostgreSQL 不提供原生二进制传输协议，驱动（如 psycopg2）默认把 BYTEA 转成十六进制字符串（x7f8b...）。直接插原始字节会报 invalid byte sequence。

• 插入前必须显式 encode(data, 'hex') 或 encode(data, 'base64')
• 读取后对应 decode(..., 'hex') 还原
• JDBC 连接串务必加 binaryTransfer=true，否则自动 hex 转义开销极大
• 别碰 pg_largeobject——需要手动管理 oid、权限、清理，现代应用基本不用

跨数据库写存储过程时，CLOB/BLOB 参数类型无法统一：Oracle 支持 IN OUT CLOB，MySQL 根本不认识这个类型。最实际的做法是放弃类型强约束，改用 VARCHAR2 或 TEXT 参数，靠应用层做长度校验和分段处理。