局部索引支持分区裁剪，全局索引不支持；局部索引每个分区对应一个表分区，查询含分区键时可精准定位；全局索引为单棵B-tree，需全索引扫描，且DDL操作易致UNUSABLE，维护成本高。
局部索引能用分区裁剪，全局索引不能
局部索引的每个分区只对应一个表分区，查询时如果 where 条件含分区键（比如 sale_date >= '2025-01-01'），oracle 可直接定位到相关分区索引段，跳过其余分区——这就是分区裁剪。全局索引是单棵 b-tree 或跨分区组织的索引结构，哪怕只查一个分区的数据，也得扫描整棵树。
常见错误现象：EXPLAIN PLAN 显示 ACCESS BY GLOBAL INDEX ROWID 且 OBJECT_NAME 是全局索引名，同时 PARTITION START/STOP 为 KEY 或 ALL，说明没裁剪。
- 局部索引 + 分区键查询：I/O 量 ≈ 单个分区大小
- 全局索引 + 同样条件：I/O 量 ≈ 全表索引大小，可能比不建索引还慢
- 非前缀局部索引（如表按
sale_date分区，索引建在customer_id上）也会失效裁剪，退化为全分区扫描
全局索引维护开销大，DDL 后容易 unusable
对分区表执行 DROP PARTITION、TRUNCATE PARTITION 或 EXCHANGE PARTITION 时，全局索引会立刻变成 UNUSABLE 状态，后续查询报 ORA-01502。局部索引则完全不受影响——删分区，对应索引分区自动删；截断分区，对应索引段自动清空。
修复全局索引必须 ALTER INDEX ... REBUILD，这是全索引扫描+排序操作，亿级数据可能跑数小时。加 UPDATE GLOBAL INDEXES 子句可避免失效，但 DDL 执行时间显著拉长，且要求大量临时表空间。
- 局部索引重建支持粒度到分区：
ALTER INDEX idx_local REBUILD PARTITION p2025_q1 - 全局索引不支持分区级重建，
REBUILD PARTITION语法直接报错ORA-14057 - 高并发写入场景下，全局索引更新可能引发严重锁竞争
唯一性约束决定是否必须用全局索引
局部索引只能保证单个分区内唯一，比如不同年份的订单号可以重复。要 enforce 全局唯一（如主键或 UNIQUE 约束），必须用全局索引——但前提是该唯一列不能是分区键本身（否则局部索引加分区键就能满足）。
典型陷阱：把 id 设为自增主键并建全局索引，却忽略 id 本身和分区键无关，导致所有写入都争抢同一索引根块，成为性能瓶颈。
- 若业务允许“分区键+唯一列”组合唯一（如
(sale_date, order_no)），优先建局部索引 - 全局唯一且无法引入分区键时，才考虑全局索引，同时评估写入压力与 DDL 频率
- 位图索引只能是局部的，不能建全局位图索引
OLTP 和数据仓库场景倾向不同
OLTP 系统常需跨分区点查（如查某用户所有订单），且对唯一性和事务一致性要求高，全局索引更常见；数据仓库多按时间范围分区，查询集中于近期分区，局部索引天然适配。
但别一刀切：即使在 OLTP 中，只要查询条件稳定命中分区键（如查“今天下单的用户”），局部索引依然更快。真正需要全局索引的，往往是那些既不能加分区键、又必须全局去重、还极少做分区 DDL 的字段。
容易被忽略的一点：全局索引的分区方式（RANGE/HASH）必须是前缀的，即索引列最左几列得是索引分区键；而局部索引的分区键强制等于表分区键，没得选。
