clob参数本身不直接写入临时表空间，但隐式触发lob缓冲、拷贝、转换或排序行为才是temp暴涨主因；如order by/group by含clob字段、nls排序规则启用、dbms_lob.substr+order by组合、绑定变量类型未显式指定、gtt中插入clob并建索引等场景均会强制磁盘排序，生成大量lob型临时段。
CLOB 参数本身不直接写入临时表空间，但 Oracle 在处理 CLOB（尤其是 IN 或 IN OUT 模式）时，隐式触发 LOB 缓冲、拷贝、转换或排序行为，才是临时表空间暴涨的真正推手。
CLOB 传参触发排序或隐式转换时，TEMP 空间被大量占用
Oracle 对 CLOB 的处理依赖于其存储方式（INLINE 还是 OUT OF LINE）和访问路径。当以下任一情况发生，就会强制走磁盘排序：
- 存储过程内部对
CLOB字段做了ORDER BY、GROUP BY、DISTINCT、UNION等操作（哪怕只是对含CLOB的视图做SELECT *） -
CLOB被当作字符串参与拼接或比较，而 NLS 排序规则（如NLS_SORT = BINARY_CI）启用时，Oracle 可能将整个CLOB内容载入临时段做字符级排序 - 使用了
DBMS_LOB.SUBSTR+ORDER BY组合，且子串长度较大，导致优化器放弃内存排序
此时 v$sort_usage 里会出现大量 LOB 类型的临时段，segtype 显示为 LOB 或 DATA，而非常规的 TEMPORARY。
CLOB 绑定变量未显式指定类型，导致隐式转换与 PGA 溢出
Java/ODP.NET/PL/SQL 调用中，若未明确将绑定参数声明为 OracleDbType.Clob 或 DBMS_SQL.VARCHAR2（对小值），Oracle 可能按默认规则推断为 VARCHAR2(4000) 并尝试截断或隐式转 CLOB，进而触发以下连锁反应：
- 绑定值被缓存为临时 LOB（
temporary LOB），生命周期由会话控制，不随 PL/SQL 块结束自动释放 - 若该临时 LOB 被用于多次 SQL 执行（如循环调用含
CLOB的 INSERT SELECT），每次都会申请新临时段，旧段仅标记为可重用，不立即归还文件空间 -
PGA_AGGREGATE_TARGET设置偏小（例如 CLOB 相关操作极易落盘，放大TEMP消耗
验证方式：
SELECT s.sid, s.username, u.tablespace, u.segtype, u.contents, u.blocks
FROM v$session s, v$sort_usage u
WHERE s.saddr = u.session_addr AND u.segtype IN ('LOB', 'TEMPORARY');
CLOB 参数在全局临时表（GLOBAL TEMPORARY TABLE）中被插入或索引，引发双重膨胀
这是最隐蔽也最危险的场景：
你定义了一个 GTT，其中某列为 CLOB，然后在存储过程中执行：
INSERT INTO my_gtt (id, clob_col) VALUES (1, p_clob_param);
此时 Oracle 不仅要为该 CLOB 分配临时段存储内容，还会——
- 若该 GTT 上建有普通索引（非函数索引），Oracle 将尝试对
CLOB列建索引条目（失败报错），或退化为全扫描+排序； - 若 GTT 后续被
ORDER BY clob_col查询，即使只查 1 行，也可能因无法使用索引而启动全 LOB 比较，强制全部载入TEMP。
更糟的是：GTTP 中的 CLOB 数据不会在事务提交后立刻释放临时空间，而是等到会话结束才由 SMON 清理，期间所有新会话都可能复用同一块膨胀后的 tempfile。
临时表空间不会因单次 CLOB 传参就崩，但一旦涉及排序、隐式转换、GTTP 或未关闭的临时 LOB 句柄，它就会像雪球一样越滚越大——而且你很难从 top SQL 里一眼看出根源，因为真正“干坏事”的往往是一行 ORDER BY 或一个没设类型的绑定参数。
