oracle 12c的interval分区仅自动创建空分区，不自动归档或清理历史数据；必须手动配合drop/exchange/move等策略实现滚动管理，否则表会持续膨胀。
oracle 12c 的 interval 分区不会“自动管理历史数据”，它只负责按规则建空分区；真正实现历史数据有序归档、清理或滚动，必须靠你手动配合策略（比如定期 drop partition、exchange、move），否则表会越积越臃肿。
INTERVAL 分区建表三要素缺一不可
建表时漏掉任意一个，插入数据就不会触发自动分区，甚至直接报错。常见错误是以为写个 INTERVAL(1) 就够了。
- 分区键必须是单列，且类型为
DATE、TIMESTAMP或NUMBER（不支持VARCHAR2或复合列） - 初始分区必须用
VALUES LESS THAN显式定义，且上限不能是MAXVALUE（否则 Oracle 无法推导下一个边界） -
INTERVAL子句必须紧跟PARTITION BY RANGE (col)后，且单位函数必须匹配粒度：按月用NUMTOYMINTERVAL(1, 'MONTH')，按天必须用NUMTODSINTERVAL(1, 'DAY')（NUMTOYMINTERVAL不接受'DAY'，否则报ORA-01867）
为什么插入历史数据会炸出一堆空分区？
这是 INTERVAL 的固有行为，不是 bug。只要插入的值 > 当前最高分区的 VALUES LESS THAN 上界，Oracle 就会一口气补全所有中间缺失分区——哪怕一条数据都没存。
- 例如当前最高分区是
P_INIT VALUES LESS THAN DATE '2026-01-01'，你执行INSERT INTO t VALUES (..., DATE '2026-07-15')，Oracle 会新建 2026-01、2026-02 … 2026-07 共 7 个分区 - 这些空分区长期存在，会拖慢
USER_TAB_PARTITIONS查询、影响分区裁剪效率，也增加元数据压力 - 根本原因：设计目标是“保证写入不失败”，而非“节省空间”
避免空分区爆炸的实操办法：预留分区 + 控制写入窗口
别指望关掉 INTERVAL 或事后清理，最有效的是在建表阶段就卡住自动扩展的起点。
- 根据业务预期写入时间范围，手动多建几个初始分区。例如明确未来 18 个月只写
2026-01-01到2027-06-30的数据，就在建表时定义从2026-01-01开始、按月递增的多个VALUES LESS THAN分区，覆盖到2027-07-01 - 这样真实数据都会落在已有分区里，不会触发自动创建
- 如果真要处理跨年历史数据导入，先用
ALTER TABLE ... SPLIT PARTITION把大分区切细，再分批 INSERT，比放任 INTERVAL 自动补更可控
已有 RANGE 分区表如何在线转 INTERVAL？
不能对非分区表或 LIST/HASH 表直接加 INTERVAL，但已有的 RANGE 分区表可以在线转换，前提是满足条件。
- 原表必须已是 RANGE 分区（哪怕只有 1 个手工分区），且不能有全局索引、物化视图依赖
- 执行：
ALTER TABLE t MODIFY PARTITION BY RANGE (col) INTERVAL (NUMTOYMINTERVAL(1,'MONTH')) (PARTITION p_old VALUES LESS THAN (...)) ONLINE;——ONLINE关键字能避免锁表 - 转换后，旧分区保留原边界，新数据才按 INTERVAL 规则落盘；已有数据不会重分布，也不会自动合并
- 如果原表是 LIST 分区，必须先
EXCHANGE出数据 →DROP表 →RECREATE为 RANGE + INTERVAL，再EXCHANGE回去
最关键的细节常被忽略：系统自动生成的分区名是 SYS_P12345 这类无意义字符串，DBMS_METADATA.GET_DDL 导出的 DDL 不包含它们，备份恢复或迁移时极易丢分区。上线前必须立刻运行 SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'YOUR_TABLE' ORDER BY partition_position 并存档结果——这不是建议，是必须动作。
