复杂查询猛吃临时表空间索引段，主因是CREATE INDEX、REBUILD或含ORDER BY/GROUP BY的大查询触发磁盘排序；需查v$sort_usage中segtype='INDEX'的会话及关联SQL，优化索引前缀覆盖、避免函数谓词，并控制重建时的并行与日志选项。
为什么复杂查询会猛吃临时表空间的索引段？
不是所有索引都会触发临时段，但某些操作会强制 oracle 把索引数据“搬进”临时表空间做中间处理——典型就是 create index、alter index ... rebuild 或带 order by/group by 的大结果集扫描。这时候即使目标列有索引，如果排序键不在索引最左前缀，或者统计信息过期，优化器仍可能放弃索引而走全表扫描 + 磁盘排序，直接打满 temp。
查清当前哪些索引重建正在占用 TEMP 段
别只盯着 SQL，先确认是不是后台索引维护在“偷偷吃空间”。运行以下语句看活跃的临时段来源：
SELECT s.sid, s.serial#, s.username, u.tablespace, u.segtype, u.extents, u.blocks FROM v$session s, v$sort_usage u WHERE s.saddr = u.session_addr;
重点关注 segtype = 'INDEX' 的行，再结合 v$sql 关联出实际执行的语句：
SELECT sql_id, sql_text FROM v$sql WHERE sql_id IN ( SELECT sql_id FROM v$session s JOIN v$sort_usage u ON s.saddr = u.session_addr WHERE u.segtype = 'INDEX' );
- 如果看到大量
CREATE INDEX ... ONLINE或ALTER INDEX ... REBUILD，说明索引维护窗口没错开，正并发抢 TEMP - 若
sql_text是普通查询但segtype为INDEX，大概率是优化器误判导致索引未被有效利用
索引设计上避开 TEMP 段膨胀的 3 个硬约束
临时段暴涨往往不是因为没索引，而是索引没对上查询模式。关键检查点：
-
ORDER BY字段必须是复合索引的**连续前缀**：比如ORDER BY dept_id, salary，索引必须是(dept_id, salary, ...)，不能是(salary, dept_id)或(dept_id, name, salary) - 带
GROUP BY的聚合，索引需覆盖所有分组字段+聚合字段（如GROUP BY region, product+SUM(sales)，索引应含(region, product, sales)） - 避免在索引字段上用函数或表达式：像
WHERE UPPER(name) = 'ABC'会让索引失效，触发全表扫描+排序，直接写到 TEMP
重建索引时控制 TEMP 消耗的实操参数
就算要重建，也别让单次操作把 TEMP 打爆：
- 加
NOPARALLEL：并行重建会为每个 PX 进程分配独立临时段，总用量翻倍甚至更多 - 用
ONLINE模式时加NOLOGGING：减少 redo 写入压力，间接降低 PGA 溢出概率 - 对超大表，改用
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL先清理碎片，再重建，避免因空间不连续触发 ORA-01652
真正难处理的不是单条 SQL，而是那些依赖临时段做中间聚合的视图嵌套或物化视图刷新——这类逻辑一旦固化，改索引不如改执行路径，得从源头重写查询结构。
