MOVE操作必然导致所有索引（含B树、函数、位图索引）变为UNUSABLE，因ROWID全部变更；必须立即重建索引、收集统计信息并处理LOB段，否则引发ORA-01502错误或性能断崖。
Move操作会直接让所有索引失效，且必须重建
非分区表执行 ALTER TABLE ... MOVE 后，所有依赖该表的索引（包括普通B树索引、函数索引、位图索引）状态都会变成 UNUSABLE。这不是“可能失效”，而是Oracle强制行为——因为MOVE会重写数据块，导致所有ROWID变更，而索引正是靠ROWID定位行的。
- 执行后必须立刻检查：
SELECT index_name, status FROM user_indexes WHERE table_name = 'YOUR_TABLE';，几乎必然看到大量UNUSABLE - 重建索引不是可选动作，而是必须补救步骤；否则后续查询走不到索引，性能断崖式下跌
- 如果表上有唯一约束或主键，对应的索引失效还会间接导致DML报错（如ORA-01502）
MOVE期间表被独占锁定，业务不可用
ALTER TABLE ... MOVE 是DDL操作，全程持有 EXCLUSIVE 表级锁。这意味着：在MOVE执行期间，任何DML（INSERT/UPDATE/DELETE）、甚至某些DDL（如加列、改注释）都会被阻塞，直到MOVE完成。
- 大表MOVE耗时长，锁表时间同步拉长，对在线业务是硬性中断
- 不像
DBMS_REDEFINITION可在线重定义，MOVE没有“无锁”变体 - 即使只MOVE一小部分数据（比如加WHERE条件），Oracle也不支持——MOVE总是整表操作
高水位线（HWM）下降的代价远超收益
MOVE确实能降低HWM、释放空间，但这是以“全表物理重写+索引重建+长时间锁表”为代价换来的。而频繁MOVE说明你正用DELETE清空数据——这本身就是反模式。
- DELETE不释放HWM，但MOVE又太重；更合理的路径是：用
TRUNCATE替代批量DELETE，或按需归档后DROP分区（如果是分区表） - 如果真要整理碎片，优先评估是否可通过
SHRINK SPACE COMPACT（需启用行移动+段压缩）实现在线收缩，它不改变ROWID，索引不受影响 - MOVE后若未及时收集统计信息，优化器仍可能沿用旧执行计划，造成性能抖动
真正难的不是“会不会MOVE”，而是没意识到：每次MOVE都在把一个本可规避的空间管理问题，升级成一次索引维护事故+一次业务停机风险+一次统计信息失准隐患。
