Oracle分区表主键必须包含分区键，否则建表报ORA-14038错误；因局部唯一索引无法跨分区保证全局唯一性，若主键不含分区键，相同值可能在多分区重复出现。
oracle 分区表的主键必须包含分区键，否则建表会直接报错 ora-14038。这不是可选项，是强制约束。
为什么主键必须显式包含分区键
Oracle 要求主键（或唯一约束）的列集合必须“覆盖”分区键，即分区键列必须是主键列的子集。根本原因是：局部唯一索引（LOCAL）无法跨分区保证全局唯一性——如果主键不含分区键，同一主键值可能出现在多个分区中，破坏唯一性语义。
- 主键隐式依赖索引，而分区表上若用
LOCAL索引（最常见且推荐），索引条目只在单个分区内有效 - 若主键不含分区键，比如分区键是
create_time、主键是id，那不同分区里完全可能出现重复的id - Oracle 不允许这种设计，所以建表时就拦截：
ORA-14038: GLOBAL partitioned index must contain the partitioning key（实际错误号常为ORA-14038或ORA-14037，取决于索引类型）
三种合法的主键写法及适用场景
核心是让主键列组合“能定位到唯一分区”，常见写法有：
-
主键 = 分区键本身：如
CREATE TABLE t (dt DATE PRIMARY KEY) PARTITION BY RANGE(dt) ...—— 最简洁，适合时间序列主键场景 -
主键 = 分区键 + 其他列：如
PRIMARY KEY (dt, id)，其中dt是分区键 —— 通用方案，兼容业务主键逻辑 -
主键含多列分区键全部列：如分区键是
(year, month)，则主键必须包含这两列（顺序无关，但必须全含）
注意：USING INDEX LOCAL 必须与上述任一形式配合，否则 Oracle 会拒绝创建局部索引。
容易踩的坑：GLOBAL 索引不是解药
有人想绕过限制，用 GLOBAL UNIQUE INDEX 配合不含分区键的主键。这语法上可行，但代价巨大：
- 全局索引在任何分区 DDL 操作（如
DROP PARTITION、SPLIT）后会失效，必须REBUILD，停机风险高 - 无法享受分区剪枝（partition pruning），查询性能退化明显
- 主键约束虽成立，但违背分区设计初衷：把大表拆开管理，却用全局结构串起来
- 备份恢复、传输表空间等运维操作复杂度陡增
真正需要全局唯一性的场景（比如跨时间分区查 ID），应靠应用层或物化视图保障，而不是牺牲分区表结构。
建表时检查分区键是否被主键覆盖
执行前快速验证方法：
- 查分区键：
SELECT column_name FROM dba_part_key_columns WHERE owner = 'YOUR_SCHEMA' AND name = 'YOUR_TABLE'; - 查主键列：
SELECT column_name FROM dba_cons_columns WHERE owner = 'YOUR_SCHEMA' AND constraint_name IN (SELECT constraint_name FROM dba_constraints WHERE table_name = 'YOUR_TABLE' AND constraint_type = 'P'); - 确认后者包含前者所有列（不区分顺序）
漏掉哪怕一个分区键列，建表就会失败。别依赖“先建表再加主键”——Oracle 在 ALTER TABLE ... ADD CONSTRAINT 时同样校验该规则。
