shrink space后索引不会自动失效，但全局索引可能因隐式move变为unusable；本地索引不受影响，加cascade维护失败易致unusable，lob索引更易失效，需分层验证状态、执行计划及统计信息。
大表收缩（SHRINK SPACE）后索引不会自动失效，但可能因隐式MOVE导致全局索引变UNUSABLE——关键在操作类型和索引范围。
SHRINK SPACE 为什么会触发索引失效
Oracle 的 SHRINK SPACE 本质是在线的“压缩+重定位”操作，它会物理移动数据块。对索引的影响取决于索引类型和是否指定 CASCADE：
- 本地索引（LOCAL）不受影响：每个分区独立维护，MOVE 只在本分区内部发生，无需重建
- 全局索引（GLOBAL）默认不参与 SHRINK：除非显式加
CASCADE子句，否则 SHRINK 完成后，全局索引状态仍是 VALID，但可能指向已移动的旧块地址——此时查不到数据或报 ORA-01502 - 加了
CASCADE后，Oracle 会尝试自动维护全局索引，但失败概率高：若索引过大、空间不足、或存在未提交事务，维护中断就会留下 UNUSABLE 状态，且不回滚 - LOB 索引（如基于 LOB 列的函数索引）极容易失效：SHRINK 前若未清理
v$transaction中残留的 LOB 写入事务，MOVE 过程中会跳过部分索引条目，导致逻辑不一致
如何验证 SHRINK 后索引是否真失效
别只看 DBA_INDEXES.STATUS，要分层确认：
- 查状态：
SELECT index_name, status, funcidx_status FROM user_indexes WHERE table_name = 'YOUR_TABLE';——status = 'UNUSABLE'是明确信号 - 查是否被优化器选用：
EXPLAIN PLAN FOR SELECT ...后查OBJECT_NAME和ACCESS_PREDICATES，确认走的是索引还是全表扫描 - 查统计信息是否同步：
SELECT last_analyzed FROM dba_tab_statistics WHERE table_name = 'YOUR_TABLE' AND object_type = 'INDEX';—— 若时间早于 SHRINK 时间，说明统计未更新，优化器可能误判成本 - 对 LOB 相关索引，额外检查：
SELECT * FROM v$transaction WHERE xidusn > 0 AND used_ublk > 0;—— 存在活跃事务就说明 SHRINK 可能没真正完成索引刷新
避免 SHRINK 导致索引失效的实操要点
核心原则：不依赖自动维护，用可控两步法替代 CASCADE：
- 收缩前先置全局索引为不可用：
ALTER INDEX idx_global UNUSABLE;—— 毫秒级，不影响业务 DML - 再执行收缩：
ALTER TABLE t SHRINK SPACE COMPACT;（或SHRINK SPACE，视碎片程度选） - 收缩完成后重建索引：
ALTER INDEX idx_global REBUILD ONLINE PARALLEL 4;—— 加ONLINE避免锁表，PARALLEL加速 - LOB 表必须额外清理：
ALTER SYSTEM FLUSH BUFFER_CACHE;+ALTER SYSTEM CHECKPOINT;，防止 DBWR 缓存旧 branch 块 - 最后强制更新统计：
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA', tabname => 'YOUR_TABLE', cascade => TRUE);——cascade => TRUE必须带，否则索引统计仍为空
真正容易被忽略的是：SHRINK 后即使索引 STATUS 显示 VALID，也可能因统计滞后或 LOB 缓存残留，让优化器绕过索引走全表扫描——这时候查 DBA_TAB_STATISTICS.LAST_ANALYZED 和 v$transaction 比反复重建索引更有效。
