列表分区插入未声明值立即报ORA-14400，因要求精确匹配VALUES中定义的值，不支持模糊匹配、NULL（除非显式声明VALUES(NULL)）或空字符串（需单独声明VALUES('')）；DEFAULT分区虽可兜底但损害性能、治理与索引。
列表分区遇到没声明的值，直接报 ORA-14400，没有兜底逻辑——除非你显式建了 DEFAULT 分区。
为什么 INSERT 会立刻失败，而不是写进某个“默认”分区
列表分区要求每个插入值必须精确匹配 PARTITION ... VALUES (...) 中的某一项。Oracle 不做模糊匹配、不自动归类、也不接受 NULL（除非分区键允许 NULL 且你单独声明了 VALUES (NULL)）。哪怕只差一个字符，比如插入 'ZZ' 但分区只定义了 'CN'、'US'，就会触发 ORA-14400。
常见错误现象：
- 从上游系统同步数据，新增了地区码
'MO'，但表里没加对应分区 - 业务字段拼写变更（如
'UK'→'GB'），旧分区未更新 - 测试数据用了占位符
'XXX'，而生产分区未覆盖该值
DEFAULT 分区不是万能兜底，而是权衡取舍
你可以用 DEFAULT 分区接收所有未明确定义的值，但它带来三个实际问题：
- 查询性能下降：优化器无法裁剪分区，全分区扫描成为常态
- 数据治理风险：掩盖了分区键值管理缺失，长期积累脏数据
- 无法与局部索引良好配合：
DEFAULT分区上的局部索引可能失效或需额外维护
示例语句（慎用）：
ALTER TABLE sales ADD PARTITION p_default VALUES (DEFAULT);
注意：DEFAULT 分区只能有一个，且不能和其他 VALUES 冲突；一旦建了，后续 ADD PARTITION 不能再含 DEFAULT。
真正可靠的扩容方式：按需添加明确值分区
对已知新增值，应走标准 ADD PARTITION 流程，而非依赖 DEFAULT：
- 确认新值范围：查源系统或日志，明确要支持的值（如
'SG'、'MY'） - 执行添加（单值或批量）：
ALTER TABLE sales ADD PARTITION p_sg VALUES ('SG');或ALTER TABLE sales ADD PARTITION p_sea VALUES ('SG', 'MY', 'TH'); - 验证分区键覆盖：
SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'SALES'不适用（列表分区high_value为空），改用：SELECT partition_name, subpartition_count, num_rows FROM user_tab_partitions WHERE table_name = 'SALES';
结合业务逻辑核对分区定义
多列列表分区同理，值必须以元组形式完全匹配，例如：VALUES ((100, 'CN'), (200, 'US')) —— 插入 (100, 'US') 仍会报错。
容易被忽略的 NULL 和空字符串陷阱
列表分区对 NULL 和空字符串 '' 是严格区分的：
-
VALUES (NULL)只接收 SQL 中的NULL，不接收空字符串 -
VALUES ('')只接收空字符串，不接收NULL - 两者都未声明时，任一出现都会触发
ORA-14400
如果业务允许，建议统一清洗数据，避免在分区键中混用 NULL 和空字符串；若必须保留，就分别建两个分区：
ALTER TABLE sales ADD PARTITION p_null VALUES (NULL);<br>ALTER TABLE sales ADD PARTITION p_empty VALUES ('');
真正的难点不在语法，而在于分区键值集是否与业务演进节奏同步——它本质上是个数据契约，一旦松动，错误就不是技术问题，而是协作断点。
