move后所有索引均失效，需显式重建；lob段、函数索引、位图索引、全局索引及物化视图日志索引等均需单独处理，并验证段位置与统计信息。
MOVE后所有索引都失效，不分类型
执行 ALTER TABLE ... MOVE TABLESPACE 后，USER_INDEXES.STATUS 会全部变成 UNUSABLE——不是部分失效，是全部。主键索引、唯一索引、普通 B-Tree 索引、函数索引、位图索引，无一例外。原因很直接：MOVE 重建了表段，所有行的 ROWID 全部变更，而索引底层依赖 ROWID 定位数据，旧地址作废，索引自然无法使用。
常见错误现象：ORA-01502: index 'SCHEMA.IDX_NAME' or partition of such index is in unusable state；或者查询突然变慢、执行计划走全表扫描，但 SELECT * FROM table 看不出异常——因为没走索引。
- 必须显式重建，Oracle 不提供自动修复机制
-
UPDATE GLOBAL INDEXES对普通表 MOVE 无效，仅适用于分区表的SPLIT/EXCHANGE等操作 - 重建前先查状态：
SELECT index_name, status FROM user_indexes WHERE table_name = 'YOUR_TABLE';
重建时要处理的不只是主键和普通索引
容易漏掉的是那些“隐形”但关键的索引结构：
- 函数索引：重建时需确保其依赖的函数、包、类型仍存在且有效，否则
ALTER INDEX ... REBUILD会报ORA-04045 - 位图索引：对并发 DML 敏感，
REBUILD期间会加锁，建议在低峰期执行 - 全局索引（分区表）：如果表是分区表且有全局索引，MOVE 单个分区不触发全局索引失效，但整表 MOVE（不推荐）或用
ALTER TABLE ... MOVE PARTITION后，全局索引必须单独REBUILD - 物化视图日志上的索引：若表启用了物化视图日志，MOVE 会失败，必须先
DROP MATERIALIZED VIEW LOG，MOVE 完再重建
LOB 列相关的索引不能靠表 MOVE 带动
含 CLOB/BLOB 的表，MOVE 表段时，LOBSEGMENT 和 LOBINDEX 默认留在原表空间，状态仍是 VALID，但指向已失效的物理位置，后续插入/更新 LOB 数据可能报 ORA-22996 或性能骤降。
必须补执行：
ALTER TABLE t MOVE LOB(col) STORE AS (TABLESPACE new_ts);- 如果该 LOB 列上有索引（如域索引），需额外确认并重建
- 检查：
SELECT segment_name, segment_type, tablespace_name FROM dba_segments WHERE owner = 'SCHEMA' AND segment_name LIKE 'SYS_LOB%'
重建索引的实操要点和坑
不是执行一条 REBUILD 就完事，几个关键点决定是否真生效：
- 非分区表：每个索引必须单独
ALTER INDEX idx_name REBUILD TABLESPACE new_ts;；不能省略TABLESPACE子句，否则仍留在旧表空间 - 想减少锁？用
REBUILD ONLINE，但要求表有主键或唯一约束，且重建中索引处于VALIDATING状态，查询可能绕过索引 - 别忘了统计信息：
DBMS_STATS.GATHER_TABLE_STATS必须跑，否则优化器仍按旧数据量估算，执行计划可能劣化 - 并行重建可提速，但注意 PGA 和临时表空间压力：
ALTER INDEX idx_name REBUILD PARALLEL (DEGREE 4) TABLESPACE new_ts;
最常被跳过的一步：验证 dba_segments 中索引段和 LOB 段是否真落在新表空间。MOVE 是分步动作，每步都可能卡在中间——表过去了，索引没动，LOB 段还钉在老地方，应用出问题时很难一眼定位到根源。
