全局索引适合主键/唯一键查询、高频点查及非分区键上的唯一约束场景；不适用于按分区键范围扫描或需大量分区裁剪的报表查询。
全局索引适合哪些查询模式
当查询条件经常跨分区（比如 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比值异常偏低
全局索引不是“更高级的索引”，它是用写放大和维护复杂度，换特定读场景下的确定性性能。一旦分区策略或查询模式漂移，它就成了最沉默的成本黑洞。
