Oracle安全写入CLOB/BLOB需先用EMPTY_CLOB()/EMPTY_BLOB()占位并FOR UPDATE锁定，再通过DBMS_LOB.WRITEAPPEND分段追加（每次≤32767字节），临时LOB须cache=>TRUE且最后调用FREETEMPORARY释放。
Oracle存储过程中怎么安全写入CLOB/BLOB而不报ORA-22922
直接拼接字符串或用TO_CLOB()处理超长内容会触发ORA-22922: nonexistent LOB value，根本原因是CLOB/BLOB未在事务上下文中正确初始化。必须用EMPTY_CLOB()或EMPTY_BLOB()占位，再通过DBMS_LOB.WRITEAPPEND流式追加。
常见错误写法：INSERT INTO t(clob_col) VALUES ('very long text...'); —— 超过4000字节就可能失败（尤其在PL/SQL块中）。
- 插入前先执行
INSERT ... VALUES (EMPTY_CLOB())，再SELECT clob_col INTO :clob_var FROM t WHERE ... FOR UPDATE - 用
DBMS_LOB.CREATETEMPORARY创建临时LOB时，务必设cache => TRUE，否则写入后读不到内容 - 写入超过32767字节的文本，必须分段调用
DBMS_LOB.WRITEAPPEND，每次传入VARCHAR2（上限32767字节） - 最后别忘了
DBMS_LOB.FREETEMPORARY释放临时LOB，否则会累积PGA内存泄漏
MySQL存储过程里没法直接操作BLOB/CLOB？得绕开
MySQL存储过程不支持DBMS_LOB类函数，也没有FOR UPDATE锁定LOB字段的语义。它的TEXT/BLOB列本质是普通字段，但大值会被截断或报Packet too large错误。
真实限制：存储过程内无法用SELECT ... INTO @var完整读取超过max_allowed_packet（默认4MB）的BLOB/CLOB；也不能用CONCAT()拼接超长CLOB。
- 改用应用层处理：把大字段读出后，在Java/Python里用
PreparedStatement.setBlob()或setClob()写入 - 若必须在数据库侧做，拆成多行存：建辅助表
blob_chunks(table_id, chunk_no, data BINARY(64K))，用循环INSERT分片 - 避免在存储过程中对
MEDIUMTEXT做LIKE '%xxx%'全文扫描——会强制全表解压，拖慢整个实例
跨数据库写存储过程时，CLOB/BLOB参数怎么传才不丢数据
Oracle允许IN OUT CLOB参数，MySQL根本不认这个类型。统一用CLOB声明参数，在Oracle中能工作，在MySQL中会直接报错Unknown type 'CLOB'。
兼容性方案只能放弃“类型即语义”，改用IN VARCHAR2 + 长度判断，或IN RAW传二进制摘要：
- Oracle侧：接收
IN CLOB参数，用DBMS_LOB.GETLENGTH判空和长度，再决定是否流式写入目标表 - MySQL侧：接收
IN TEXT参数，但需提前检查CHAR_LENGTH(param) （对应<code>MEDIUMTEXT），超长则拒绝 - 如果调用方是JDBC，注意
setClob(1, reader)在MySQL驱动里实际走的是setString()隐式转换，遇到含NUL字符的CLOB会截断
流式读取CLOB时，为什么DBMS_LOB.SUBSTR只返回前4000字节
DBMS_LOB.SUBSTR(clob, 32767, 1)看似能取32K，但返回类型是VARCHAR2，而Oracle中VARCHAR2在SQL层最大就是4000字节（12c+启用MAX_STRING_SIZE=EXTENDED后才到32767）。所以即使参数写了32767，结果仍被截断。
真正流式读，必须用DBMS_LOB.READ配合RAW或VARCHAR2缓冲区循环读取：
- 声明
buffer VARCHAR2(32767)，用DBMS_LOB.READ(clob, amount, offset, buffer)分次读 - 每次
amount不能超过32767，且offset从1开始（不是0） - 读完后
amount返回实际字节数，为0表示EOF，别依赖DBMS_LOB.GETLENGTH预判——它对未提交的临时LOB可能不准
最易忽略的一点：DBMS_LOB.READ读CLOB时，buffer必须声明为VARCHAR2，若误用CLOB类型变量接收，会静默失败且不报错。
