interval分区仅在insert时按需创建：插入值超当前最高分区上限才自动生成中间分区，且须满足range+date/timestamp+显式初始分区三条件；自动命名sys_p、表空间不可控；where含函数或绑定变量将导致剪枝失效。
INTERVAL 分区只响应 INSERT，不预建分区
Oracle 的 INTERVAL 分区根本不会“提前”或“定时”创建未来分区——它只在你执行 INSERT 时，发现插入值严格大于当前最高分区的 HIGH_VALUE，才按 NUMTOYMINTERVAL(1,'MONTH') 自动补全缺失的全部中间分区（含空档）。比如当前最大分区上界是 DATE '2024-06-01'，你插了 DATE '2025-03-15'，Oracle 会一口气建出 2024-07 到 2025-03 共 9 个新分区。
常见误操作：
- 以为建完表就自动有未来分区 → 实际一个都没有，
USER_TAB_PARTITIONS里只看到初始分区 - 用
SELECT或UPDATE触发 → 完全无效，只有INSERT才可能触发 - 插入值 ≤ 当前最高分区上界（如上界是
2024-01-01，插2024-01-01或更早）→ 不触发 - 插入
NULL到分区键列 → 直接报ORA-14400，语句失败，分区也不生成
建表语法必须满足三个硬性条件
缺一不可，否则 INTERVAL 形同虚设：
- 分区类型必须是
RANGE（不是LIST、HASH或复合） - 分区键必须是
DATE或TIMESTAMP类型（NUMBER理论支持但极少用，字符串如'202407'会报ORA-14751） - 建表时必须显式定义至少一个
VALUES LESS THAN初始分区，且边界必须是确定字面量：用DATE '2024-01-01'或TO_DATE('2024-01-01','YYYY-MM-DD')；不能用SYSDATE、ADD_MONTHS等运行时函数
错误示例：INTERVAL '1' MONTH（Oracle 不认）、START WITH 子句（不存在）、VALUES LESS THAN (SYSDATE)（建表时报错）。
自动分区名和表空间无法控制，必须手动干预
所有自动生成的分区名都是 SYS_P 开头加数字（如 SYS_P123456），你没法自定义；更重要的是，它们默认全部落在原表所在表空间，不会按年/月自动分到 TS_2025、TS_2026 这类专用空间。
若需隔离表空间，只能事后手动移动：
- 查最新分区：
SELECT partition_name FROM USER_TAB_PARTITIONS WHERE table_name = 'YOUR_TABLE' ORDER BY high_value DESC FETCH FIRST 1 ROW ONLY - 执行移动：
ALTER TABLE your_table MOVE PARTITION SYS_P123456 TABLESPACE ts_2026 - 注意：该操作会锁分区、产生大量 redo，不适合写入密集场景
所以如果生产环境强依赖表空间按年划分，INTERVAL 反而是陷阱，不如放弃，改用调度任务 + ALTER TABLE ... ADD PARTITION 手动控制。
WHERE 条件写错会导致分区剪枝失效
即使分区已存在，查询也未必走剪枝。优化器需要静态推导过滤范围，一旦条件带函数或绑定变量，就容易全表扫描：
-
WHERE dt_column > TRUNC(SYSDATE)→TRUNC阻断常量传播 -
WHERE dt_column BETWEEN :start_dt AND :end_dt→ 绑定变量未赋值或为NULL时剪枝失效 -
WHERE TO_CHAR(dt_column, 'YYYYMM') = '202607'→ 函数导致无法下推，必扫全表
正确写法必须是字面量、无函数、覆盖整月：WHERE dt_column >= DATE '2026-07-01' AND dt_column 。
真正麻烦的从来不是“怎么建”，而是“建完之后怎么让数据进对分区、查询走对分区”。这两点稍有偏差，INTERVAL 就从自动化工具变成隐蔽故障源。
