Oracle临时表高并发下争抢TEMP资源，因共享空间导致排序/写入排队，引发direct path write temp等待、响应延迟及ORA-01652；需结合PGA优化、集合替代、CTE物化及分区临时表分层治理。
临时表在高并发下会争抢TEMP表空间资源
Oracle的临时表数据默认写入TEMP表空间，而这个空间是所有会话共享的。当上百个并发会话同时执行INSERT INTO tmp_table SELECT ...时，会集中触发临时段分配、排序区扩展、磁盘I/O排队等操作。你看到的direct path write temp等待事件飙升，往往就是这个原因。
常见错误现象包括：同一SQL在单用户下毫秒级响应，100并发时平均耗时跳到2秒以上；AWR报告中Temp space usage峰值接近表空间上限；v$sort_segment显示大量活跃临时段未释放。
- 会话级临时表（
ON COMMIT PRESERVE ROWS）更危险——数据不随事务提交清空，长期占用临时段，容易被误认为“内存泄漏” - 事务级临时表（
ON COMMIT DELETE ROWS）虽自动清理，但频繁的LOAD AS SELECT仍带来大量buffer gets和latch争用 - 若
TEMP表空间使用本地管理（LMT），且未设置足够大的uniform size，小段碎片会加剧争抢
集合（COLLECTION）避免I/O，但需注意内存边界
PL/SQL中的TYPE t_tab IS TABLE OF ...这类内存集合，全程在PGA中操作，不经过TEMP，自然绕开磁盘I/O瓶颈。但它把压力转到了内存上——每个会话都持有一份副本，100并发 × 每份10MB = 1GB PGA消耗，很容易触发ORA-04030（out of process memory）。
使用场景判断很关键：如果中间结果集稳定在几万行以内、字段较窄（如仅NUMBER或VARCHAR2(10)），集合更稳；若要存几十万行带CLOB或长文本的记录，集合反而拖垮PGA。
- 别用
FORALL INSERT往临时表灌数据后再查——这等于主动制造两次I/O（写+读） -
BULK COLLECT INTO到集合后，用MEMBER OF或COUNT做筛选，比再建临时表JOIN快得多 - 注意
PL/SQL array size隐式限制：默认100行一批，大集合要显式设LIMIT避免反复上下文切换
替代方案不是非此即彼，而是分层选型
真正的问题不在“用不用临时表”，而在“哪一层该承担中间状态”。高并发系统里，越靠近应用层处理中间数据，数据库侧压力越小。
- 能用应用内存（Java List / Python list）缓存的，就别进数据库——尤其只是做简单去重、映射、分组
- 必须在DB内处理的，优先走WITH子句（CTE）：优化器可能选择
MATERIALIZE或直接流式处理，不落盘 - 实在要落盘，考虑分区全局临时表（
CREATE GLOBAL TEMPORARY TABLE ... PARTITION BY ...），缓解单段争用（Oracle 12c+支持） - 监控项必须加：
v$tempseg_usage查实时占用，gv$session_longops盯住Sort/Hash类长时间操作
最易被忽略的点：临时表索引没统计信息
很多人给临时表建了INDEX，却忘了DBMS_STATS.GATHER_TABLE_STATS对临时表无效——Oracle不收集临时表的统计信息。优化器永远按“空表”估算，导致本该走索引的WHERE col = ?变成全表扫描，而你还在奇怪为什么加了索引没效果。
解决方案只有两个：显式加/*+ INDEX(t idx_name) */提示；或者改用WITH + MATERIALIZE + INLINE组合，让优化器在计划内可控地物化。
临时表不是银弹，它解决的是“逻辑隔离”和“多次复用”的问题，不是“性能加速”的万能开关。高并发下，每一次INSERT /*+ APPEND */ INTO temp_xxx，都在悄悄透支TEMP和PGA两道防线。
