必须用 alter index ... rebuild online parallel n，否则串行或离线重建会阻塞dml导致业务中断，且可能因临时表空间耗尽引发ora-01652；重建后须立即收集索引统计信息并校验状态。
直接用 ALTER INDEX ... REBUILD ONLINE PARALLEL N，别用串行重建或离线重建——否则业务写入会卡死，且可能触发临时表空间耗尽。
为什么串行重建或不加 ONLINE 会导致业务中断
全局索引重建默认是离线操作：整个重建过程锁住索引段，所有依赖该索引的 INSERT/UPDATE/DELETE 都会被阻塞，直到重建完成。Oracle 12c+ 虽支持在线重建，但若漏掉 ONLINE 关键字，就退化为传统锁表模式。
- 串行重建耗时长，尤其 TB 级索引，可能持续数小时
- 不加
ONLINE时，SELECT可读，但任何 DML 都在等待enq: TX - row lock contention或enq: IV - contention - 并行度未设上限（如
PARTITION 8）且 PGA 不足时，会大量 spill 到临时表空间，引发ORA-01652
重建命令必须带的三个参数
只写 REBUILD 是危险的起点。生产环境必须显式控制行为边界：
-
ONLINE：允许 DML 并发执行，仅对索引结构加短暂SRX锁 -
PARALLEL N：N 建议设为 CPU 核数 × 0.7（例如 16 核配PARALLEL 11），避免资源争用 -
NOPARALLEL（重建后立即执行）：防止后续 DML 继承并行度，引发隐式并行争用
完整示例：
ALTER INDEX idx_global REBUILD ONLINE PARALLEL 8;<br>ALTER INDEX idx_global NOPARALLEL;
重建后必须立刻收集统计信息
重建不刷新 dba_indexes.num_rows 和 clustering_factor，CBO 仍按旧统计估算成本，极易选错执行计划——比如明明有索引却走全表扫描，或反向选择索引导致性能雪崩。
- 执行：
EXEC DBMS_STATS.GATHER_INDEX_STATS('SCHEMA_NAME', 'IDX_GLOBAL'); - 不要依赖
COMPUTE STATISTICS子句（已弃用且不可靠） - 若索引跨多个表空间或含函数表达式，需确认
DBMS_STATS权限和对象可访问性
最容易被忽略的坑：重建中途失败，状态卡在中间
网络中断、实例崩溃、临时表空间满，都可能导致 REBUILD ONLINE 中断。此时索引状态可能变成 UNUSABLE 或 VALID 但数据不一致——Oracle 不会自动回滚索引段变更，也不会报错提示。
每次重建前务必先查：
SELECT index_name, status FROM user_indexes WHERE index_name = 'IDX_GLOBAL';
如果已是
UNUSABLE，不能重试原命令；必须先 ALTER INDEX IDX_GLOBAL UNUSABLE（毫秒级），再跑带 ONLINE 的重建。
