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 参数，靠应用层做长度校验和分段处理。
