Oracle建表时VALUES LESS THAN仅接受静态字面量（如DATE '2024-01-01'），禁用TO_DATE()等运行时函数，否则报ORA-00922；边界须严格递增，末分区慎用MAXVALUE，建议预留明确未来边界并提前创建空分区。
VALUES LESS THAN 写成动态函数会直接报错
Oracle 建表时不允许在 VALUES LESS THAN 里用 TO_DATE()、ADD_MONTHS() 或任何运行时求值的表达式。它只接受静态字面量或可编译期解析的表达式（如 DATE '2024-01-01'）。写成 VALUES LESS THAN (TO_DATE('202401', 'YYYYMM')) 会触发 ORA-00922: missing or invalid option，不是语法错，而是 DDL 强制要求边界可确定。
常见错误包括：
- 用字符串拼接日期，比如
'2024-01-01'没加DATE前缀 → 被当字符处理，分区逻辑失效 - 把分区键列名直接写进
VALUES LESS THAN (created_at)→ 语法非法，必须是具体值 - 边界值未严格递增，比如先建了
LESS THAN (DATE '2024-03-01')，再加LESS THAN (DATE '2024-02-01')→ 报ORA-1508: invalid range
补分区比改边界更安全，但得避开 MAXVALUE
范围分区的已有边界不能修改，只能新增分区或合并。如果发现漏了 2024-07 这个区间，正确做法是执行 ALTER TABLE t ADD PARTITION，而不是试图“扩大”上一分区的上限——Oracle 不允许。
但要注意：MAXVALUE 是个硬性终点。一旦末分区用了 MAXVALUE，就无法再 ADD PARTITION；必须先用 REORGANIZE PARTITION 拆分它，才能插入新边界。所以首次建表时，别急着把最后一个分区设成 MAXVALUE，留一个明确的未来边界（比如 DATE '2025-01-01'），后续再手动补。
实操建议：
- 按月分区时，边界统一设为每月 1 日零点（
DATE '2024-07-01'），不是月末，否则最后一天数据会掉出范围 - 提前建好未来 3–6 个月的空分区，避免每次插入都卡在
ORA-14400 - 新增分区语句必须保证
VALUES LESS THAN值 > 上一分区的HIGH_VALUE，查USER_TAB_PARTITIONS确认
分区裁剪失效常被误判为边界问题
看起来像边界没覆盖到，实际可能是查询没走裁剪。比如 WHERE 条件写了 create_time = :v1，但绑定变量 :v1 类型被推断为 VARCHAR2，导致隐式转换，优化器放弃裁剪——这时即使边界完全正确，也会全表扫描，还可能误以为是分区建错了。
验证是否真因边界导致失败：
- 查
SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'T'，注意high_value是 RAW，需用DBMS_METADATA.GET_DDL展开看真实值 - 用具体字面量测试插入：
INSERT INTO t VALUES (..., DATE '2024-07-15', ...)，看是否仍报ORA-14400 - 检查 WHERE 是否对分区键用了函数：
TRUNC(create_time) = DATE '2024-07-01'→ 改成create_time >= DATE '2024-07-01' AND create_time
时间类型混用会让边界计算失准
分区键用 DATE，但插入值是 TIMESTAMP，或反过来，会导致边界比较异常。Oracle 会做隐式转换，但精度丢失（比如 TIMESTAMP '2024-07-01 23:59:59.999' 转 DATE 变成 2024-07-02），结果本该落到 p202407 的数据被路由到 p202408，甚至超出所有分区。
解决方案很直接：
- 建表时统一用
DATE或TIMESTAMP，不要混；推荐DATE（兼容性好、存储小、边界清晰） - 应用层插入前显式转类型：
TO_DATE(:ts_str, 'YYYY-MM-DD HH24:MI:SS')或CAST(:ts_val AS DATE) - 别依赖客户端自动转换，尤其 JDBC 驱动版本不一致时，
setDate()和setTimestamp()行为可能不同
