如何创建分区表的全局索引_Global Index的适用场景与维护成本分析

全局索引适合主键/唯一键查询、高频点查及非分区键上的唯一约束场景；不适用于按分区键范围扫描或需大量分区裁剪的报表查询。

全局索引适合哪些查询模式

当查询条件经常跨分区（比如 WHERE user_id = 12345，而 user_id 不是分区键），且需要快速定位单行或小范围数据时，GLOBAL INDEX 才真正有用。它把整个表的索引项按索引键值全局排序，不跟分区绑定。

常见错误现象：用 CREATE INDEX ... GLOBAL 给按时间分区的订单表建在 order_no 上，结果发现按日期范围查（WHERE create_time BETWEEN ...）反而变慢——因为全局索引无法剪枝分区，优化器可能放弃走索引。

• 适用场景：主键/唯一键查询、高频点查、非分区键上的唯一约束
• 不适用场景：按分区键范围扫描、大量分区裁剪的报表类查询
• 注意：GLOBAL INDEX 默认是前缀分区（GLOBAL PARTITION BY RANGE），但多数数据库（如 oracle）只允许按索引键分区，不能按任意列；postgresql 没原生全局索引，得靠 BRIN 或应用层模拟

重建全局索引为什么常卡住

全局索引更新必须串行化所有分区的数据变更，DML 高峰期建索引会严重阻塞写入，甚至触发长时间锁等待。这不是“慢”，而是设计层面的冲突。

典型错误：在业务高峰期执行 ALTER table ... ADD GLOBAL INDEX，接着发现插入超时、ORA-00054: Resource busy 或 PostgreSQL 的 lock timeout。

• 建索引期间，每个 INSERT/UPDATE/delete 都要同时维护全局 B-tree 结构，IO 和 CPU 开销陡增
• Oracle 中 NOLOGGING 可跳过重做日志，但实例崩溃后索引不可用；PG 中没有等效机制
• 建议操作：选低峰期 + 设置 PARALLEL 4（Oracle）或分批 CREATE INDEX CONCURRENTLY（PG），但后者仍需两次扫描全表

分区 DDL 对全局索引的影响

只要动了表结构或分区定义，GLOBAL INDEX 就大概率失效或进入 UNUSABLE 状态，不是“自动同步”的。

常见错误现象：执行 ALTER TABLE ... DROP PARTITION 后，原本能走索引的 select 突然变全表扫描，EXPLAIN 显示索引状态为 UNUSABLE。

• DROP PARTITION / SPLIT PARTITION / MERGE PARTITION 均导致全局索引失效（Oracle 默认行为）
• 修复方式不是 REBUILD，而是加 UPDATE GLOBAL INDEXES 子句（Oracle），否则索引元数据和物理结构脱节
• PostgreSQL 分区表本质是继承树，ATTACH/DETACH 子表不影响父表上的普通索引，但所谓“全局索引”只是逻辑概念，需手动在每个子表上创建并保持一致

比局部索引多出的维护成本在哪

核心不在空间，而在每次写操作的路径长度和锁粒度：全局索引让一次 INSERT 必须定位到全局 B-tree 的某个叶子块，而不是本地分区内的短路径。

容易被忽略的一点：高并发写入下，多个会话争抢同一个索引块（尤其是右边界叶子块），引发 enq: TX - index contention（Oracle）或 buffer busy wait（PG），性能毛刺明显。

• 局部索引（LOCAL INDEX）每个分区独立一棵 B-tree，写入天然分散
• 全局索引合并写放大：一条记录插入，可能触发索引页分裂 + 多个层级的父节点更新 + undo 日志膨胀
• 监控重点不是索引大小，而是 v$segment_statistics（Oracle）里的 gc current blocks received 或 PG 的 pg_stat_all_indexes.idx_scan 与 idx_tup_read 比值异常偏低

全局索引不是“更高级的索引”，它是用写放大和维护复杂度，换特定读场景下的确定性性能。一旦分区策略或查询模式漂移，它就成了最沉默的成本黑洞。