分区表索引策略需权衡本地与全局索引：本地索引按分区键过滤高效、维护成本低，但不支持非分区键唯一约束；全局索引支持任意字段点查和唯一性保障，但分区变更易致失效。
分区表的索引策略直接影响查询性能和维护成本。本地索引与全局索引不是互斥选择，而是需按业务场景权衡：本地索引天然对齐分区结构，适合按分区键过滤的查询；全局索引独立于分区，适合跨分区点查或非分区键字段的高效检索。
本地索引（Local Index）
本地索引为每个分区单独构建一个索引段，索引分区与表分区严格一一对应，且索引键必须包含分区键（Oracle 要求，其他数据库如 PostgreSQL 分区表+BRIN/GIN 索引逻辑类似）。
- 优点：DML 操作（如 truncate、drop partition）只影响对应索引分区，不触发全局索引重建，维护开销低
- 缺点：无法直接支持非分区键字段上的唯一约束（除非该字段也参与分区），且跨分区查询需合并多个索引扫描结果，执行计划可能变宽
- 适用场景：高频按时间/地区等分区键查询；批量加载后快速清理旧分区；OLAP 类分析任务中以分区为单位过滤
全局索引（Global Index）
全局索引是单个统一索引结构，覆盖全表所有分区数据，可基于任意列建立（包括非分区键），支持唯一性约束，但其生命周期与表分区解耦。
- 优点：支持任意字段的高效点查（如用订单号查单条记录），执行计划稳定；可建唯一索引保障业务完整性
- 缺点：修改分区（如 split、drop、exchange）会导致全局索引失效，需 rebuild 或维护为 unusable 状态，影响可用性；索引本身可能成为写入瓶颈
- 适用场景：高并发 OLTP 中频繁按主键或业务唯一键查询；需要强唯一性保证（如用户手机号唯一）；分区变更频率低、可接受维护窗口
混合使用建议
实际生产中常组合使用：主键/唯一键走全局索引，确保一致性与点查效率；分区键+常用查询字段组合建本地索引，支撑范围扫描与分区裁剪。
- 例如：按 order_date 范围分区的订单表，order_id 建全局唯一索引，(order_date, status) 建本地索引
- 注意：Oracle 中全局索引默认不可分区，但支持全局分区索引（Global Partitioned Index），可按另一维度（如 hash order_id）拆分，缓解单点压力
- PostgreSQL 12+ 支持真正意义上的分区表原生索引，CREATE INDEX 默认创建本地索引；若需全局效果，需在父表上建普通 B-tree 并配合约束排除（constraint exclusion）或使用 pg_pathman 扩展
关键决策检查点
选型前确认以下四点：
- 最常被 WHERE 过滤的字段是否是分区键？若是，本地索引大概率更优
- 是否存在必须保证唯一性的非分区键字段？存在则需全局索引（或组合分区键）
- 分区维护操作（如每月归档）是否要求 7×24 不中断？若是，应避免依赖全局索引的 DDL
- 查询是否经常跨多个分区且返回少量行？此时全局索引的索引范围扫描比多次本地索引扫描更高效
