ALTER TABLE ... MOVE 会导致非本地索引失效，因ROWID变更使索引指向错误位置；需检查状态、重建索引并更新统计信息；MOVE与SHRINK目标不同，前者段级重建离线快速，后者原地紧缩需ASSM且可部分在线。
ALTER TABLE ... MOVE 为什么会导致索引失效
执行 alter table ... move 后，表的物理存储位置彻底变更，所有行的 rowid 都会改变。而 oracle 索引（尤其是普通 b-tree 索引）是基于原始 rowid 构建的，一旦 rowid 失效，索引条目就指向了错误或不存在的位置，查询时会报 ora-01502: index 'xxx' or partition of such index is in unusable state。
- 唯一例外是全局分区索引（Global Index），它不依赖单个表段的物理位置，但 Move 操作仍需显式指定
UPDATE GLOBAL INDEXES才能保持可用 - 本地分区索引（Local Index）不受影响，因为每个分区索引只绑定对应分区段
- 函数索引、位图索引等同样全部失效，无一幸免
MOVE 操作必须搭配的三步清理动作
单纯执行 ALTER TABLE t MOVE 只完成了物理重建，后续不处理就会让业务直接中断。真正落地必须补全以下操作：
- 检查索引状态：
SELECT index_name, status FROM user_indexes WHERE table_name = 'T';—— 几乎所有非 Local 索引都会显示UNUSABLE - 重建索引：
ALTER INDEX idx_name REBUILD ONLINE;（推荐加ONLINE避免锁表）；若不能停写，也可分批重建 - 更新统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'T', CASCADE => TRUE);—— 否则优化器仍按旧数据分布估算执行计划，可能继续走错路
MOVE 和 SHRINK SPACE 的关键差异在哪
很多人误以为 MOVE 是 SHRINK SPACE 的“老版本替代”，其实二者设计目标和适用边界完全不同：
-
MOVE是“段级复制重建”：分配新段、逐行拷贝、原子切换，必然离线（期间 DML 阻塞），但速度通常比SHRINK快得多，尤其在大表上 -
SHRINK SPACE是“原地紧缩+水位重置”：依赖ROW MOVEMENT，先 compact 再降 HWM，可在线做 compact 阶段，但第二步降 HWM 仍需短暂排他锁 -
MOVE不要求表空间启用 ASSM；SHRINK强制要求本地管理 + ASSM，否则报ORA-10636: row movement is not enabled或直接失败 -
MOVE后表的PCTFREE/PCTUSED等参数按当前 DDL 值重设；SHRINK完全保留原有存储参数
执行 MOVE 前最容易被忽略的三个检查点
跳过这些检查，轻则操作失败，重则引发主键冲突、LOB 访问异常或分区元数据错乱：
- 确认表是否含
LOB列：SELECT column_name, data_type FROM user_tab_columns WHERE table_name = 'T' AND data_type LIKE '%LOB%';—— 若有，MOVE 必须显式指定LOB (col) STORE AS (TABLESPACE ts_name)，否则默认放在 SYSAUX 或 SYSTEM 表空间，极其危险 - 检查是否有
ENABLE ROW MOVEMENT被意外开启：SELECT row_movement FROM user_tables WHERE table_name = 'T';—— 如果是ENABLED，MOVE 可能触发隐式行移动逻辑冲突，建议先DISABLE ROW MOVEMENT - 验证目标表空间剩余空间是否 ≥ 当前表大小 × 1.2：
SELECT bytes/1024/1024 FROM dba_segments WHERE segment_name = 'T';—— Move 过程中新旧段并存，空间不足会直接ORA-01652
MOVE 的“快”是有代价的：它不解决行迁移（Row Migration）本身，只把迁移过的行一并搬到新位置；而 SHRINK COMPACT 会主动重组块内布局。要不要用 MOVE，得看你的停机窗口、表空间类型、LOB 存在与否——不是所有高 HWM 表都适合一刀切地 Move。 
