会，ALTER TABLE ... MOVE PARTITION 会加排他锁，整个分区在移动期间不可读写，持续至操作完成；需低峰期执行，配合 UPDATE INDEXES、统计信息收集及 LOB 显式处理。
ALTER TABLE ... MOVE PARTITION 会锁表吗？
会，而且是排他锁（exclusive），整个分区在 move partition 过程中不可读写。这不是“短暂阻塞”，而是持续到移动完成——对大分区可能长达数分钟甚至小时。
常见错误现象：ORA-00054: resource busy and acquire with NOWAIT specified 或应用端突然大量超时、连接堆积。
- 必须安排在业务低峰期执行，不能依赖“快速完成”预期
- 如果表启用了行迁移（
ROW MOVEMENT），不影响MOVE PARTITION，但该设置本身不解决锁问题 - 在线重定义（
DBMS_REDEFINITION）可规避锁表，但复杂度高、需额外空间，冷热分层场景通常不值得
MOVE PARTITION 到新表空间的正确语法和关键参数
核心命令是 ALTER TABLE ... MOVE PARTITION ... TABLESPACE ...，但漏掉几个隐含行为会导致后续出问题。
使用场景：把历史订单分区 P_2023 从默认表空间迁到只读/压缩的 TBS_ARCHIVE。
- 索引不会自动重建或迁移，必须显式处理：
UPDATE INDEXES或单独ALTER INDEX ... REBUILD PARTITION ... TABLESPACE ... - 分区级统计信息会被清空，迁移后应立刻收集：
DBMS_STATS.GATHER_TABLE_STATS(..., GRANULARITY => 'PARTITION') - 如果原分区有 LOB 字段，必须加
LOB (col_name) STORE AS (TABLESPACE ...)子句，否则 LOB 段仍留在旧表空间
示例：
ALTER TABLE orders MOVE PARTITION P_2023 TABLESPACE tbs_archive LOB (detail_blob) STORE AS (TABLESPACE tbs_archive) UPDATE INDEXES;
MOVE PARTITION 后为什么查询变慢了？
不是因为数据搬错了，而是执行计划失效或统计信息丢失导致优化器选错路径。
性能影响最常发生在两个环节：
- 全局索引失效：如果表有全局索引（非分区索引），
MOVE PARTITION后状态变成UNUSABLE，查询走全表扫描而非索引 - 统计信息陈旧：即使加了
UPDATE INDEXES，它只重建索引结构，不更新统计信息；优化器仍按旧分布估算，可能误判分区裁剪失效 - 表空间 I/O 特性变化：新表空间若用归档存储（如 Oracle Heat Map + ADO），首次访问可能触发透明解压，延迟明显
冷热分层中，MOVE PARTITION 和 COMPRESS 的配合要点
MOVE PARTITION 本身不压缩数据；想实现冷数据压缩，必须显式加 COMPRESS FOR ARCHIVE LOW（12c+）或 COMPRESS BASIC（旧版本）。
参数差异直接影响效果：
-
COMPRESS FOR ARCHIVE LOW：高压缩比，适合只读归档，但解压开销大；写入不可行（会报错） -
COMPRESS BASIC：仅字典压缩，对重复值有效，支持 DML，但压缩率有限 - 压缩必须在
MOVE时指定，不能事后ALTER；且压缩后分区无法再MOVE回非压缩表空间（除非先NOCOMPRESS）
示例（带压缩迁移）：
ALTER TABLE orders MOVE PARTITION P_2023 TABLESPACE tbs_archive COMPRESS FOR ARCHIVE LOW LOB (detail_blob) STORE AS (TABLESPACE tbs_archive);
真正容易被忽略的是：分区移动后，应用侧是否还向该分区插入数据。冷热分层失败，90% 是因为没同步调整分区策略（比如没加 MAXVALUE 或没切分新分区），导致新数据继续写进刚挪走的“冷区”。
