NOCOPY 对大型 LOB 参数几乎无效，因为 Oracle 默认仅传递 LOB locator 而非数据，NOCOPY 提示被静默忽略，无法减少拷贝或提升性能。
为什么 NOCOPY 对大型 LOB 参数几乎无效
直接说结论：NOCOPY 在 Oracle 函数/过程的 BLOB 或 CLOB 参数上**通常不加速**，甚至可能被忽略。原因在于：Oracle 对 LOB 类型的参数传递机制与普通标量类型完全不同——它默认就只传 LOB locator（定位符），而非实际数据块。所以加 NOCOPY 不会减少内存拷贝，也不会提升性能。
常见误判场景是看到文档里写“NOCOPY 可避免大对象复制”，就以为对 BLOB 也适用。实际上，它真正起作用的是 VARCHAR2（超长时）、PL/SQL RECORD、ASSOCIATIVE ARRAY 等值传递开销大的类型。
如何验证 NOCOPY 是否生效于 LOB 参数
最可靠的方式是查 USER_ARGUMENTS 视图，看参数是否被标记为 IN OUT NOCOPY 或 OUT NOCOPY：
SELECT argument_name, in_out, nocopy FROM user_arguments WHERE object_name = 'YOUR_PROCEDURE_NAME' ORDER BY position;
你会发现，即使你在声明里写了 OUT NOCOPY CLOB，查询结果中 nocopy 列仍是 NO。这是因为 Oracle 内部强制将 LOB 参数视为“locator 传递”，NOCOPY 提示会被静默忽略（无报错，也不生效）。
-
NOCOPY只对IN OUT和OUT参数有意义，IN参数本身就不拷贝值（只读 locator） - 若参数是
IN OUT且你修改了 LOB 内容（如用DBMS_LOB.WRITE），Oracle 会自动在调用返回前同步 locator 指向的数据，这步无法跳过 - 使用
DBMS_PROFILER或DBMS_HPROF对比加/不加NOCOPY的执行时间，结果基本一致
真正影响大型 LOB 性能的关键点
与其纠结 NOCOPY，不如关注这些实际起效的操作：
- 确保 LOB 列定义为
ENABLE STORAGE IN ROW（小 LOB 存在行内），否则每次访问都要额外 I/O 定位 segment - 批量操作优先用
DBMS_LOB.LOADFROMFILE或DBMS_LOB.COPY，避免逐字节WRITE - 函数中避免重复调用
DBMS_LOB.GETLENGTH—— 它可能触发隐式读取，缓存长度值更稳妥 - 如果函数需返回新 LOB，用
DBMS_LOB.CREATETEMPORARY+RETURNING子句，比拼接字符串再转 LOB 快得多 - 注意事务隔离：在
READ COMMITTED下多次读同一 LOB 可能因版本链导致重复读块
什么时候该考虑绕过 PL/SQL 处理 LOB
当函数逻辑涉及大量解析、转换或流式处理（如 XML 解析、JSON 提取、图像元数据读取），纯 PL/SQL 效率远低于外部工具。这时更现实的方案是：
- 用 Java Stored Procedure（通过
loadjava部署）直接操作oracle.sql.BLOB/CLOB，避开 PL/SQL 的 LOB 封装层 - 在应用层处理（如 Python +
cx_Oracle），用cursor.var(oracle.DB_TYPE_BLOB)绑定，支持流式读写 - 对超大文件（>100MB），改用 Oracle Wallet +
UTL_HTTP或外部表加载，避免 LOB 缓冲区耗尽
真正卡住性能的，从来不是参数传递方式，而是 LOB 数据的物理布局、访问模式和上下文切换成本。盯着 NOCOPY 往往意味着还没看清瓶颈在哪。
