Oracle要求局部唯一索引必须包含全部分区键列以保证跨分区唯一性，否则报ORA-14039；全局唯一索引无需包含分区键但需显式指定GLOBAL分区策略，且分区逻辑独立于表分区。
唯一索引必须包含所有分区键列
Oracle 要求局部唯一索引（LOCAL）的键必须包含分区键的所有列，否则建索引会直接报错 ORA-14039。这不是限制，而是机制使然：局部索引按分区独立维护，若唯一键不含分区键，跨分区就无法保证全局唯一性。
例如表按 sale_date 范围分区，且定义为分区键：
CREATE TABLE sales ( id NUMBER, sale_date DATE, region VARCHAR2(10) ) PARTITION BY RANGE (sale_date) ( PARTITION p_2023 VALUES LESS THAN (DATE '2024-01-01'), PARTITION p_2024 VALUES LESS THAN (DATE '2025-01-01') );
下面这条语句会失败：
CREATE UNIQUE INDEX idx_sales_id ON sales(id) LOCAL;
因为 id 不含分区键 sale_date，Oracle 无法确保不同分区中 id=100 的行不重复。
- 正确做法是把分区键加进索引：
CREATE UNIQUE INDEX idx_sales_id_date ON sales(id, sale_date) LOCAL; - 如果业务上真正要求的是全局唯一
id，那就不能建LOCAL索引，得用GLOBAL -
GLOBAL唯一索引不要求包含分区键，但它是单一分区结构，可能成为并发热点
GLOBAL 唯一索引的分区策略要手动指定
建 GLOBAL 唯一索引时，Oracle 不允许默认“自动分区”，必须显式声明 GLOBAL PARTITION BY 方式，否则报错 ORA-14029。
常见写法有两种：
- 全局非分区唯一索引（单个B树段）：
CREATE UNIQUE INDEX idx_sales_id_global ON sales(id) GLOBAL; - 全局分区唯一索引（按哈希或范围分片）：
CREATE UNIQUE INDEX idx_sales_id_hash ON sales(id) GLOBAL PARTITION BY HASH (id) PARTITIONS 4;
注意：PARTITION BY RANGE 在 GLOBAL 索引中仅支持日期/数字类型，且分区键必须是索引列的前缀子集；而 HASH 更常用，能均衡IO，但范围查询性能下降。
如果原表是按 sale_date 分区，但想按 id 哈希建全局唯一索引，没问题 —— GLOBAL 索引的分区逻辑完全独立于表分区。
LOCAL 唯一索引对 INSERT/UPDATE 的约束行为
局部唯一索引只在单个分区内强制唯一，**不阻止不同分区出现相同键值**。这意味着：INSERT INTO sales VALUES (1, DATE '2023-06-01', 'CN') 和 INSERT INTO sales VALUES (1, DATE '2024-06-01', 'US') 可以同时成功 —— 因为它们落在不同分区，且索引是 LOCAL。
这种行为常被误认为“唯一性失效”，其实是设计如此。是否接受它，取决于业务语义：
- 若
id确实只需在时间范围内唯一（比如每日流水号），LOCAL+(id, sale_date)是合理选择 - 若
id是系统主键、必须全表唯一，则只能选GLOBAL索引，或改用SEQUENCE+ 应用层校验兜底 - UPDATE 某行导致其分区键变更（如更新
sale_date跨分区）时，LOCAL唯一索引会触发跨分区检查，可能引发ORA-00001—— 这是隐式全局校验，但代价高
复合唯一键中分区键位置影响索引可修剪性
即使满足“包含分区键”的前提，局部唯一索引的列顺序也影响执行计划能否利用分区剪枝。Oracle 优化器只对索引前缀匹配分区键的查询做剪枝。
假设建了索引 CREATE UNIQUE INDEX idx_sales_region_id ON sales(region, id, sale_date) LOCAL;，虽然含 sale_date，但它不是前导列。
此时查询 SELECT * FROM sales WHERE sale_date = DATE '2023-12-01' 无法使用该索引做分区剪枝，会扫描所有分区。
- 推荐把分区键放在复合唯一索引最左侧：
(sale_date, id)或(sale_date, region, id) - 如果高频查询是
WHERE region = 'CN' AND id = 123，又想保留剪枝能力，可考虑函数索引或额外建一个LOCAL非唯一索引辅助 - 不要为了“看起来更自然”把业务主键放前面，优先保障分区键前置 —— 这是分区表索引设计中最容易被忽略的性能点
