不能添加新default分区，因为oracle要求列表分区的最后一个分区必须是且只能有一个default分区，add partition会违反此元数据约束而报ora-14074。
不能添加新的 DEFAULT 分区。 Oracle 明确禁止在已有 DEFAULT 分区的列表分区表上执行 ADD PARTITION 操作，会直接报错 ORA-14074。
为什么 ADD PARTITION 会失败？
Oracle 的列表分区设计中，DEFAULT 分区具有唯一性和兜底语义：它必须存在且只能有一个，用于收纳所有未被其他 VALUES 显式覆盖的值（包括 NULL）。一旦创建了 DEFAULT 分区，DDL 层面就锁死了“不能再新增任何分区”的规则。
- 执行
ALTER TABLE t ADD PARTITION part_x VALUES ('9')→ 报错：ORA-14074: partition bound must be MAXVALUE for LAST partition - 即使你删掉原有
DEFAULT分区，再加新分区，也仍需重新定义一个DEFAULT——但此时已不满足“LAST partition must be DEFAULT”约束 - 根本原因不是语法限制，而是 Oracle 内部元数据校验强制要求：列表分区的最后一个分区必须是
DEFAULT，且不可变更顺序
想扩展列表分区的正确做法
真正可行的路径只有两种，取决于你是否能接受停写或重建：
- 如果表可短时停写：用
EXCHANGE PARTITION+ 新建表方式间接扩容。先建一张结构相同但含完整VALUES列表（不含DEFAULT）的新表，把原表数据按需分发到新表各分区，再用EXCHANGE替换原表 - 如果必须在线、且只增少量值：放弃
DEFAULT，改用显式枚举所有可能值（含NULL），并预留足够多的分区。例如：PARTITION p_null VALUES (NULL)、PARTITION p_9 VALUES ('9')，后续再通过SPLIT PARTITION拆分（但注意：列表分区不支持SPLIT，此路不通 —— 所以实际只剩第一种方案） - 更现实的选择：直接重建表。导出数据 →
DROP原表 → 用完整VALUES列表 + 新增项重CREATE→ 导入。虽耗时，但语义清晰、无兼容风险
DEFAULT 分区对查询和 DML 的隐性影响
很多人忽略的是：DEFAULT 分区会破坏分区裁剪的确定性。只要 WHERE 条件里没精确匹配到某个显式 VALUES 分区的键值，优化器就不得不扫描 DEFAULT 分区 —— 即使你查的是 id = '9'，而 '9' 实际并不存在于任何分区定义中，它仍会落到 DEFAULT 里，导致无法排除该分区。
- 执行
SELECT * FROM list_example WHERE id = '9'→ 执行计划显示访问PARTITION: ALL或至少包含part_default -
INSERT INTO list_example VALUES (9, 'xxx', 'yyy')成功，但数据实际进了part_default，而非你预期的“新分区” - 监控
user_tab_partitions.num_rows会发现part_default行数持续增长，成为性能黑洞
真正的安全边界在于：列表分区的分区键值集合应尽量封闭、可枚举；一旦引入 DEFAULT，就等于放弃了分区设计的可控性——后续所有维护动作都绕不开这个“万能兜底”，而 Oracle 不给你留缝去修补它。
