不能直接释放空间。merge partitions仅物理搬迁数据并删除源分区段，不压缩数据、不降低hwm、不回收索引碎片；真正释放空间需后续执行shrink space compact、重建索引及刷新统计信息。
分区合并（MERGE PARTITIONS）真能释放空间吗
不能直接释放空间。MERGE PARTITIONS 本质是逻辑重组：把两个或多个分区的数据物理搬移到一个新分区段中，再删掉源分区段。它不压缩数据、不调整 HWM、不回收索引碎片——只是“搬家+删旧”。如果你的 sales_2022_q1 和 sales_2022_q2 各占 15GB，合并后新分区仍约 30GB，dba_segments 查到的大小基本不变。
真正释放空间靠的是后续动作：搬迁后必须显式执行 ALTER TABLE ... SHRINK SPACE COMPACT（需先 ENABLE ROW MOVEMENT），否则高水位线卡在原位置；索引也得单独 ALTER INDEX ... REBUILD，否则叶块空洞照旧。
什么场景下该用 MERGE 而不是 DROP 或 TRUNCATE
MERGE 的核心价值不是省空间，而是保结构、保统计信息、保依赖对象连续可用。比如你有按月分区的订单表，但 2022 年全年数据已归档且不再查询，又不能删分区（因下游报表视图、物化视图日志、分区级授权都还依赖该分区名），这时 MERGE PARTITIONS 就比 DROP PARTITION 安全得多。
-
DROP PARTITION会直接删段、丢统计信息，物化视图日志可能报ORA-12096； -
TRUNCATE PARTITION虽保留分区定义，但会重置高水位线，若未配SHRINK，后续插入仍从高位写，空间没真还给 OS； -
MERGE后分区数减少，但表结构、索引定义、约束、权限全在，应用无感，且 AWR 历史段统计（DBA_HIST_SEG_STAT）仍可追溯。
MERGE 操作前必须检查的三件事
漏查任意一项，轻则操作失败，重则引发长时间锁等待或索引失效：
- 确认目标表空间有足够连续空间：MERGE 会先建新分区段，再删旧段。若目标表空间剩余最大空闲块（
MAX(bytes)fromdba_free_space）小于待合并数据量，会报ORA-1652； - 检查本地索引状态：如果索引是
LOCAL，且各被合并分区的索引子分区落在不同表空间（如idx_2022_q1在ts_his_low，idx_2022_q2在ts_his_med），MERGE 后新索引分区将继承第一个分区的表空间，可能违反存储策略； - 验证分区键值范围是否可合并：例如
PARTITION p2022_q1 VALUES LESS THAN (DATE'2022-04-01')和PARTITION p2022_q2 VALUES LESS THAN (DATE'2022-07-01')可合，但若中间缺p2022_q3，Oracle 不允许跳着 MERGE，会报ORA-14252。
合并后空间没变小？重点盯这三处
很多人执行完 MERGE 就去查 dba_segments，发现 bytes 没降，以为操作无效。其实空间释放卡在三个地方：
- 表段本身：没跑
SHRINK SPACE COMPACT→ 高水位线不动，dba_extents里 extent 数和位置全没变； - 本地索引：每个子分区都是独立段，MERGE 只动数据分区，索引子分区仍是旧结构 → 必须对新生成的索引分区执行
ALTER INDEX ... REBUILD PARTITION p2022_h1； - 全局索引：若存在 GLOBAL 索引，MERGE 后状态变为
UNUSABLE，但不会自动报错，查询时才触发ORA-01502→ 必须立刻ALTER INDEX ... REBUILD，否则业务就断。
最易被忽略的是：DBA_HIST_SEG_STAT 里历史快照仍记录着旧分区的 I/O 和空间增长趋势，合并后若不手动刷新统计（DBMS_STATS.GATHER_TABLE_STATS），优化器可能继续按错误的 BLOCKS 值选执行计划。
