确认索引段占用临时表空间：查询v$sort_usage中segtype='INDEX'的记录，结合v$sql定位对应SQL，若为CREATE/ALTER INDEX或未走索引的排序查询，则证实索引相关操作正持续消耗TEMP。
Oracle索引段异常膨胀，不是“索引变大了”这么简单——它往往意味着某类操作正在持续把索引数据反复搬进搬出，或者优化器在绕过索引走磁盘排序，临时段被当成索引中转站。先查 v$sort_usage 里 segtype = 'INDEX' 的会话，再顺藤摸瓜看 SQL，比直接杀会话或重建索引更稳。
怎么确认是索引段在吃临时表空间？
临时表空间里出现大量 segtype = 'INDEX' 的记录，说明 Oracle 正在用 TEMP 做索引相关中间处理，典型场景包括：CREATE INDEX、ALTER INDEX ... REBUILD、带 ORDER BY/GROUP BY 的大结果集查询（尤其当排序字段没被索引前缀覆盖时）。
- 运行：
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 AND u.segtype = 'INDEX'; - 若返回多行且
blocks持续增长，基本锁定是索引重建或排序类操作在占用 - 注意：普通查询语句如果也触发
segtype = 'INDEX'，大概率是优化器误判——比如WHERE UPPER(name) = 'ABC'导致索引失效，被迫全表扫描+排序
为什么索引重建会卡住并持续占 TEMP？
重建本身不一定会暴涨 TEMP，但并发、并行和日志选项组合不当，会让单次操作变成 TEMP 杀手。
-
PARALLEL会为每个 PX 进程分配独立临时段，总用量可能翻倍甚至更多；NOPARALLEL更安全 -
ONLINE模式默认写 redo，PGA 容易溢出，间接推高 TEMP 使用；加NOLOGGING可缓解（前提是可接受丢失部分恢复能力） - 局部索引（
LOCAL）执行REBUILD默认只处理当前分区，其他分区仍碎片化——得用ALTER INDEX ... REBUILD PARTITION或显式指定UPDATE GLOBAL INDEXES
索引段物理膨胀 ≠ 碎片，但都得靠统计信息说话
光看 dba_segments.bytes 没用，leaf_blocks 和 clustering_factor 才反映真实存储效率。统计信息过期，优化器就以为索引很“紧凑”，实际 I/O 却爆炸。
- 查碎片信号：
SELECT leaf_blocks, clustering_factor FROM dba_indexes WHERE index_name = 'YOUR_IDX';，若leaf_blocks远大于理论值（如行数 ÷ 每块平均键数），且clustering_factor接近表总行数，就是典型碎片+数据分布差 - 重建前必须跑：
DBMS_STATS.GATHER_INDEX_STATS，否则重建完优化器还是按旧统计估算成本 - 高并发写场景下，
REBUILD需要 SS 锁，容易被业务 DML 卡住；此时COALESCE（只整理现有块、不申请新空间）更稳妥
别漏掉 SYSAUX 里的“影子索引段”
某些组件（如 SM/ADVISOR、AUDSYS）内部维护的元数据表，底层也是索引结构，但它们不显现在 dba_indexes 里，却会撑大 SYSAUX 表空间。
- 查源头：
SELECT occupant_name, ROUND(space_usage_kbytes/1024/1024, 2) AS gb FROM v$sysaux_occupants WHERE space_usage_kbytes > 0 ORDER BY space_usage_kbytes DESC; - 若
SM/ADVISOR占几十 GB，重点盯WRI$_SQLSET_PLAN_LINES这类 LOB 表——它背后有隐式索引，且清理机制依赖 MMON，一旦 MMON 异常，这些索引段就持续膨胀 -
AUDSYS.AUD$UNIFIED如果排前三，说明统一审计日志没清理，不能直接 truncate，得用DBMS_AUDIT_MGMT清理
索引段异常膨胀最危险的地方，是它常常藏在“看起来正常的 SQL”后面——一条带 ORDER BY 的报表查询，可能因为索引字段顺序不对，就把整个结果集拖进 TEMP 做排序；一次没加 NOPARALLEL 的重建，可能让 TEMP 瞬间打满。查 v$sort_usage + 对应 SQL + 索引定义三者交叉验证，比盲目调参数或删段更可靠。
