oracle interval分区需建表时用numtoyminterval或numtodsinterval指定单位，values less than必须为确定日期/数值，且至少定义一个初始分区；仅当insert数据严格大于当前最高分区上界时才触发自动建分区，不支持字符串、多列或非date/timestamp/number类型分区键。
建表时必须写对 INTERVAL 和 VALUES LESS THAN
Oracle 的 INTERVAL 分区不是“开个开关就自动跑”，它完全依赖建表语句的结构契约。最常失败的原因是语法写错：INTERVAL 子句必须用 NUMTOYMINTERVAL(1, 'MONTH')（年/月）或 NUMTODSINTERVAL(1, 'DAY')（日/时/分/秒），不能写成标准 SQL 的 INTERVAL '1' MONTH——这会直接报 ORA-14751。
VALUES LESS THAN 也必须是确定值，比如 DATE '2024-01-01' 或 TO_DATE('2024-01-01', 'YYYY-MM-DD')；不能用 SYSDATE、CURRENT_DATE 这类运行时函数，因为建表时刻就要算出边界。
- 正确示例：
PARTITION p_init VALUES LESS THAN (DATE '2024-01-01') - 错误写法：
VALUES LESS THAN (SYSDATE)或INTERVAL '1' MONTH - 必须至少定义一个初始分区，否则建表报
ORA-14020
插入数据才触发新分区，不是定时生成
Interval 分区不会在后台“自动扫描时间并建分区”，它只在执行 INSERT 且插入值超出当前最高分区的 HIGH_VALUE 时，才按需生成一个或多个新分区。这意味着：
-
SELECT、UPDATE、DELETE都不触发建分区 - 插入
sale_date = DATE '2023-12-15'，而现有分区上限是DATE '2024-01-01'，也不会建新分区 - 如果当前最大分区只到
2024-06-01，但你插入2025-03-15，Oracle 会一口气补全中间所有月分区（2024-07 到 2025-03），不跳过 - 若插入失败（如唯一索引冲突、权限不足、约束违反），分区也不会生成
验证是否生效：查 USER_TAB_PARTITIONS，看 HIGH_VALUE 是否增长，且 PARTITION_NAME 出现类似 SYS_P12345 的命名。
RANGE 分区键类型必须是 DATE/TIMESTAMP 或 NUMBER
Interval 只支持 PARTITION BY RANGE，且分区键只能是 DATE、TIMESTAMP 或数值型（NUMBER、INTEGER 等）。字符串、RAW、LOB 等类型都不行。
常见误用场景：
- 用
VARCHAR2存日期（如'202408'），即使内容像年月，也不被识别为可 interval 的键 - 分区键是复合列（多列），但 Oracle 的 interval 不支持多列 range，只支持单列
- 想对
LIST或HASH分区启用 interval —— 不可能，语法直接报错
如果业务真要用字符串年月，得先建虚拟列：CREATE VIRTUAL COLUMN ym AS TO_NUMBER(TO_CHAR(create_time, 'YYYYMM'))，再以该虚拟列为分区键。
自动分区后管理逻辑没变，别漏掉关键动作
Interval 省了 ALTER TABLE ADD PARTITION，但归档、清理、索引维护这些事一点没少。尤其要注意：
- 自动生成的分区名固定为
SYS_P*，无法自定义，也无法指定表空间——全部落在主表默认表空间，容易撑爆 - 本地索引（
LOCAL）随分区自动创建，但全局索引（GLOBAL）不会，删旧分区前必须UPDATE GLOBAL INDEXES或重建 - 没有 “自动删除旧分区” 功能，仍需手动
ALTER TABLE DROP PARTITION或用EXCHANGE PARTITION归档 - 表空间配额和段空间管理要提前规划，否则某次插入突然触发批量建分区，可能直接耗尽空间
真正可控的自动化只发生在建表那一刻：选对 NUMTOYMINTERVAL 单位、确认键类型、预留足量表空间。之后是否建分区，只取决于插入数据是否越界——没有后台线程，也没有运行时参数调控。这点最容易被当成“功能没生效”而反复折腾。
