子查询本身不占临时空间，真正导致TEMP爆满的是其引发的排序、哈希连接、去重或物化操作；Oracle 21c优化器易误估嵌套行数，造成PGA分配不足而spill至磁盘。
为什么子查询会让TEMP表空间突然爆满
子查询本身不占临时空间，真正触发溢出的是它诱发的排序、哈希连接、去重或物化操作。Oracle 21c 的优化器在嵌套结构里容易误估行数——比如子查询返回100行，但外层JOIN后实际产出200万行，而优化器仍按100行分配PGA内存，结果一执行就spill到磁盘。
典型高危组合包括：
-
ORDER BY写在子查询里（对外层无效，纯属白占内存） -
DISTINCT+IN/EXISTS嵌套，尤其当子查询字段无索引时 - 视图定义含
GROUP BY或UNION，导致select_type = DERIVED全量物化 -
WITH子句被自动物化但只引用一次，反而因LOAD AS SELECT写磁盘变慢
怎么快速定位是哪个子查询在吃TEMP
别靠猜，直接查执行计划里的“溢出信号”：
- Oracle：查
v$sort_usage关联v$session，确认segtype = 'SORT'的会话正在跑哪条SQL；再用EXPLAIN PLAN看是否有TEMP TABLE TRANSFORMATION操作符 - MySQL：
EXPLAIN FORMAT=tree里看Extra是否出现Using temporary，且只出现在子查询行 - PostgreSQL：
EXPLAIN (ANALYZE, BUFFERS)中Plan Rows远大于预期输出行数（如LIMIT 10却显示95万）
绕过TEMP暴涨的实操改写法
核心不是去掉括号，而是切断中间结果膨胀链，帮优化器跳过必须物化的路径：
- 删掉子查询里的
ORDER BY，除非配合FETCH FIRST或ROWNUM做截断 - 用
JOIN替代IN/EXISTS，尤其当子查询字段有索引时：SELECT t1.* FROM t1 INNER JOIN (SELECT DISTINCT id FROM t2) t2 ON t1.id = t2.id - 对
WITH子句加提示控制行为：/*+ INLINE */强制不物化，/*+ MATERIALIZE NO_MERGE */仅当确定复用≥2次时才用 - 避免在子查询里用
JSON_VALUE、VECTOR_DISTANCE等新函数——它们在物化时可能报ORA-30926，只能回退内联
临时表空间本身的配置陷阱
即使SQL写得再干净，配置错也会让问题放大：
-
DEFAULT_TEMP_TABLESPACE不能设多个表空间共用同一逻辑名，否则RAC下会话随机绑定不同tempfile，引发I/O争用 - 临时表空间不支持
UNIFORM SIZE，建的时候写EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M会直接报ORA-12907；正确写法只有CREATE TEMPORARY TABLESPACE ... TEMPFILE - 临时段分配由SYSTEM硬编码控制：前1MB用64KB extent，1–64MB用1MB，64MB以上用8MB——你根本没法调，也别纠结该设成1M还是4M
临时表空间暴满往往不是单点问题，而是SQL写法、执行路径、表空间配置三层叠加的结果。最容易被忽略的是：你以为在优化子查询，其实真正要盯住的是v$sort_usage里那个segtype = 'SORT'的会话，以及它背后那条没走索引的GROUP BY。
