多表关联撑爆TEMP表空间主因是HASH JOIN或SORT-MERGE JOIN导致PGA溢出至临时段，而非表数据量本身大；关键诱因包括驱动表未走索引、连接字段类型不一致或隐式转换致索引失效，执行计划中TempSpc值（如2.4GB）即为溢出量。
为什么多表关联会突然撑爆TEMP表空间
不是因为表本身大，而是Oracle在做HASH JOIN或SORT-MERGE JOIN时，把中间结果集全写进临时段——尤其当驱动表没走索引、或连接字段类型不一致（比如VARCHAR2对CHAR）、或隐式转换导致索引失效时，PGA根本装不下，直接溢出到TEMP。你看到执行计划里TempSpc列标着“2.4GB”，那基本就是这个原因。
检查关联字段是否真用了索引
别只看EXPLAIN PLAN里有没有INDEX RANGE SCAN，得确认它用在了JOIN条件上：
- 查
dba_indexes确认字段上有索引，且status = 'VALID'，不是UNUSABLE - 用
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST'))看实际执行的STARTS和A-Rows，如果某索引扫描STARTS=1但A-Rows=0，说明压根没命中 - 检查字段类型是否严格一致：
SELECT data_type, data_length FROM dba_tab_columns WHERE table_name IN ('T1','T2') AND column_name = 'JOIN_COL';，不一致就加函数索引或改字段类型
强制走NESTED LOOPS避免哈希/排序开销
当小表（NESTED LOOPS比HASH JOIN更省TEMP——它不建哈希表，也不排序，逐行probe即可：
- 加提示：
/*+ USE_NL(t2) LEADING(t1) */，让t1作驱动表，t2走索引回表 - 确保
t2连接字段有高效索引，且clustering_factor低（SELECT clustering_factor FROM dba_indexes WHERE index_name = 'IDX_T2_JOIN'） - 禁用自适应计划（12c+）：
ALTER SESSION SET "_optimizer_adaptive_plans" = FALSE;，防止优化器中途切回HASH JOIN
临时表空间爆满时，先别急着加文件
加文件只是掩盖问题。真正要盯的是正在占用TEMP的会话：
- 查谁在吃空间：
SELECT se.username, se.sid, se.serial#, su.tablespace, su.used_blocks*8/1024 AS mb_used FROM v$session se, v$sort_usage su WHERE se.saddr = su.session_addr ORDER BY mb_used DESC; - 如果发现某个SQL反复出现，
KILL SESSION前先ALTER SYSTEM CANCEL SQL（12c+），避免事务回滚又刷TEMP -
ALTER TABLESPACE TEMP COALESCE只能合并空闲extent，对已分配但未释放的临时段无效；真要清理，得等对应会话结束，或重启库触发SMON回收
最常被忽略的一点：执行计划过期。200万行的表统计信息半年没更新，优化器还按1万行估算，选错连接方式，TEMP瞬间打满——所以DBMS_STATS.GATHER_TABLE_STATS不是可选项，是必选项。
