Oracle把CLOB和BLOB统称为大对象类型，但很多开发者对它们的处理方式还停留在普通VARCHAR2列的水平。在建表时声明一个CLOB列，Oracle并不会把数据直接塞进表的数据块里，而是先在行内放一个叫LOB定位器的小结构，真正的内容被分配到独立的LOB段。这个机制有好有坏：好处是表本身可以保持较小的行体积，坏处是读写LOB必须绕一段路，如果代码写得不对，性能会差好几个数量级。下面从JDBC读取、PL/SQL操作、临时LOB释放三个角度来拆解。
JDBC读取：放弃getString，改用流式接口
Java代码里最常见的取CLOB写法是调用ResultSet的getString方法。对于几百KB的文本这个做法没有太大问题，但如果是几十MB的合同扫描件或者日志原文，getString会把整个字段加载到JVM堆里，一个并发请求就可能把堆撑爆。JDBC规范早就提供了对应的流式接口：getCharacterStream用于CLOB，getBinaryStream用于BLOB。这两个方法返回的是Reader或InputStream，数据从Oracle服务器端按块传输，应用内存里只需要维护一个缓冲区。
使用流式读取时要注意一个细节：连接不能提前关闭，ResultSet也必须保持打开状态。很多人在try-with-resources里把Connection、Statement、ResultSet都放在一个括号里，结果读到一半连接被关掉了，抛出ORA-17027或者Stream closed异常。正确做法是先循环读取流内容，处理完毕后再统一关闭资源。另外，如果结果集设置了fetch size，LOB流的读取性能和fetch size没有直接关系，Oracle驱动会按照LOB块的大小单独取数据。
// 不推荐：一次性加载大字段
String content = rs.getString("CONTENT");
byte[] fileData = rs.getBytes("ATTACHMENT");
// 推荐：使用流式读取
Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(
"SELECT CONTENT, ATTACHMENT FROM DOCUMENT WHERE ID = ?");
ps.setLong(1, docId);
ResultSet rs = ps.executeQuery();
if (rs.next()) {
Clob clob = rs.getClob("CONTENT");
Reader reader = clob.getCharacterStream();
char[] buffer = new char[1024];
StringBuilder sb = new StringBuilder();
int len;
while ((len = reader.read(buffer)) != -1) {
sb.append(buffer, 0, len);
}
reader.close();
Blob blob = rs.getBlob("ATTACHMENT");
InputStream in = blob.getBinaryStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] byteBuffer = new byte[4096];
int bytesRead;
while ((bytesRead = in.read(byteBuffer)) != -1) {
baos.write(byteBuffer, 0, bytesRead);
}
in.close();
}
上面的代码里ByteArrayOutputStream仍然把二进制数据缓冲在内存中，如果需要落盘或者直接转发给Web响应流，应该把InputStream直接传给Files.copy或者ServletResponse的输出流，中间不要再经过内存的字节数组。Oracle JDBC驱动从12c开始也支持用rs.getObject(index, InputStream.class)这种简写形式，底层行为一致，但代码更简洁。
PL/SQL中dbms_lob的读取与写入
存储过程中处理大字段，几乎绕不开dbms_lob这个内置包。它提供了一组操作LOB的基础方法，包括读取片段、写入片段、追加内容和比较。最简单的读法是用dbms_lob.read函数，它需要一个缓冲区变量来接收数据。缓冲区声明为VARCHAR2类型时最大只能到32767字节，所以处理超过32KB的CLOB需要分段循环读取，每次读一部分追加到目标变量中。
写入方面，dbms_lob.write和dbms_lob.append是最常用的两个过程。write可以指定LOB内部的偏移位置，适合覆盖已有内容；append则直接在末尾追加，适合逐段拼接。对于大块文本，可以用dbms_lob.copy从一个LOB复制到另一个LOB，避免在PL/SQL里反复做类型转换。下面这个存储过程演示了如何拼接两个CLOB字段，并且把结果写回目标表。
CREATE OR REPLACE PROCEDURE MERGE_CLOB_CONTENT(
p_source_id IN NUMBER,
p_target_id IN NUMBER,
p_separator IN VARCHAR2 DEFAULT CHR(10)
) AS
v_source_clob CLOB;
v_target_clob CLOB;
v_offset NUMBER := 1;
v_chunk_size CONSTANT PLS_INTEGER := 8000;
v_buffer VARCHAR2(8000);
v_amount PLS_INTEGER;
BEGIN
SELECT CONTENT INTO v_source_clob FROM DOCUMENT WHERE ID = p_source_id FOR UPDATE;
SELECT CONTENT INTO v_target_clob FROM DOCUMENT WHERE ID = p_target_id FOR UPDATE;
IF p_separator IS NOT NULL THEN
dbms_lob.append(v_target_clob, p_separator);
END IF;
v_amount := dbms_lob.getlength(v_source_clob);
WHILE v_offset <= v_amount LOOP
v_buffer := NULL;
dbms_lob.read(v_source_clob, LEAST(v_chunk_size, v_amount - v_offset + 1), v_offset, v_buffer);
dbms_lob.append(v_target_clob, v_buffer);
v_offset := v_offset + v_chunk_size;
END LOOP;
UPDATE DOCUMENT SET CONTENT = v_target_clob WHERE ID = p_target_id;
COMMIT;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK;
RAISE;
END MERGE_CLOB_CONTENT;
/
注意这里的FOR UPDATE子句，它的作用是锁住对应行，防止其他事务在读取和写入之间修改LOB内容。Oracle对LOB的锁粒度比较粗，更新任意一行中的LOB列时，通常会锁住整行甚至整个LOB段。如果两个事务同时操作同一个LOB，第二个事务会阻塞等待，直到第一个事务提交或回滚。所以处理大字段的存储过程要尽量缩短锁定时间，不要一边读取一边做耗时操作，比如调用外部HTTP接口或者做复杂计算。
针对超大批量文本，还有一种常见的做法是把CLOB转换成多个VARCHAR2片段处理，例如dbms_lob.substr配合偏移循环。但这种方式的效率远不如直接使用dbms_lob.read，因为substr每次都会从LOB定位器开始定位，时间复杂度是O(n)级别，反复调用会让整个循环变成O(n²)。如果不得不用substr，至少要把偏移量递进控制好，避免每次都从开头扫描。
临时LOB的生命周期与资源释放
Oracle内部有个概念叫临时LOB，它和持久化LOB的区别是不存储在数据库表里，而是存在于会话或调用的临时空间中。临时LOB常见于函数返回值、变量赋值和PL/SQL内部运算。比如声明一个CLOB变量，然后调用dbms_lob.createTemporary创建临时LOB，操作完成后如果不调用dbms_lob.freeTemporary释放，这部分空间会一直保留到会话结束。对于长连接的Web应用，会话可能存活几个小时甚至几天，临时LOB不断累积最终会撑爆临时表空间。
下面这段匿名块演示了正确的临时LOB管理方式。注意最后在异常分支里也要释放临时LOB，否则一旦前面的代码抛出异常，释放操作被跳过，临时LOB就泄漏了。
DECLARE
v_temp_clob CLOB;
v_result_clob CLOB;
BEGIN
dbms_lob.createTemporary(v_temp_clob, TRUE);
FOR rec IN (SELECT CONTENT FROM DOCUMENT WHERE ROWNUM <= 10) LOOP
dbms_lob.append(v_temp_clob, rec.CONTENT);
dbms_lob.append(v_temp_clob, CHR(10));
END LOOP;
v_result_clob := v_temp_clob;
INSERT INTO DOCUMENT_ARCHIVE(ID, CONTENT) VALUES (seq_doc.NEXTVAL, v_result_clob);
dbms_lob.freeTemporary(v_temp_clob);
COMMIT;
EXCEPTION
WHEN OTHERS THEN
IF v_temp_clob IS NOT NULL THEN
dbms_lob.freeTemporary(v_temp_clob);
END IF;
ROLLBACK;
RAISE;
END;
/
JDBC里的Clob和Blob对象也涉及资源释放。从getClob或getBlob获取的对象在ResultSet关闭后就不可用了，但如果你的应用使用了连接池，连接不会真正销毁，而是归还到池中复用。这时如果代码没有显式调用free方法（JDBC 4.0引入），LOB的资源可能不会立即释放，造成连接池中的连接越来越重。从Oracle 11g开始，Clob和Blob接口都支持free方法，处理完毕后调用它可以主动通知驱动释放服务端资源。
大字段查询的性能与索引策略
当表里包含CLOB或BLOB列时，一个常见的性能误区是SELECT *。很多ORM框架默认查询所有列，如果表里有几万条记录且每条包含几MB的LOB内容，一次列表查询就可能把数据库内存和网络带宽全部打满。正确的做法是在列表场景下只查询业务需要的非LOB列，LOB列等用户点击详情时再单独加载。SQL层面可以用SELECT t.ID, t.TITLE FROM DOCUMENT t这种显式列名来替代SELECT *。
另一个容易被忽略的是LOB段和表数据块的存储关系。默认情况下，Oracle会为CLOB创建独立的LOB段，但如果LOB列开启了ENABLE STORAGE IN ROW，小于4000字节的内容会直接存在表行内，大内容才会溢出到LOB段。对于文本长度分布不均匀的业务场景（比如大部分记录只有几百字的备注，少数记录有几万字的合同），开启行内存储可以减少小内容访问时的额外IO。相反，如果所有内容都很大，应该使用DISABLE STORAGE IN ROW并指定合理的CHUNK大小，让LOB段的块分配更贴近实际读写模式。
全文检索方面，Oracle提供Oracle Text组件可以对CLOB列建立CONTEXT类型索引，支持中文分词和模糊匹配。这类索引比普通的B树索引更适合大文本搜索，但索引维护成本高、同步策略复杂。如果业务只是偶尔做简单的LIKE模糊查询，可以考虑把合法的小字段提取到独立的VARCHAR2列上建立索引，大字段本身不参与搜索。对于必须对大字段做复杂检索的场景，Oracle Text是更专业的选择。
大字段的写入还有一个性能问题：每次更新LOB列时，Oracle会在LOB段中分配新的空间，旧的LOB数据块会被标记为可重用，但不会立即回收。频繁更新大字段会导致LOB段膨胀。针对这种情况，可以通过ALTER TABLE DOCUMENT MODIFY LOB (CONTENT) (SHRINK SPACE)手工回收空间，或者定期重建LOB段。在执行收缩前先用SELECT查询DBA_LOBS视图确认LOB段的实际使用量，避免盲目收缩导致IO开销过大。
最后补充一点，很多开发者会问BFile是不是处理大文件的更优方案。BFile本质上是数据库里保存一个指向操作系统文件的指针，数据本身不进入数据库。它适合只读场景，比如图片服务器上的静态资源路径映射。但如果文件需要事务一致性、需要备份或者需要跨库同步，把二进制数据存入BLOB比BFile更可靠。选择哪种类型取决于业务对一致性和存储成本的权衡，而不是简单地认为数据库不应该存文件。
Oracle CLOBBLOB大字段流式读写修改时间：2026-09-23 22:42:46