为什么Oracle分区表的Global索引维护会带来巨大的Undo压力

Global索引导致Undo暴增，因其强制串行化所有分区写操作、分裂B-tree引发指数级Undo生成、RAC下远程Undo加剧争用，且建索引期间DML仍需同步维护索引，Undo压力远超回收能力。

Global索引更新必须串行化所有分区的数据变更

每次insert/update/delete操作，只要涉及global索引列，oracle就必须定位并修改全局b-tree的单个叶子块——这个过程不是只改一个分区，而是要保证整棵树的一致性，所以所有写操作都得排队走同一把锁。高并发下，大量事务在等待索引块的latch或tx锁，undo段被迫长期持有前镜像，根本来不及回收。

• ATOMIC_REFRESH => TRUE（默认）的物化视图刷新会触发全量重建，Global索引随之被DELETE+INSERT重刷，Undo暴涨是必然结果
• 分区DDL如DROP PARTITION不带UPDATE GLOBAL INDEXES子句，索引进入UNUSABLE状态，后续DML会先尝试修复索引结构，额外生成大量Undo
• Global索引无法分区裁剪，优化器常放弃走索引而选全表扫描，但业务仍强制加INDEX hint，导致无效索引维护持续消耗Undo

Global索引的物理结构放大Undo写入量

局部索引写入只影响本分区索引树，路径短、块少；Global索引则要把新键值插入到跨所有分区的统一B-tree中，可能触发根块分裂、分支块分裂、叶块分裂——每一次分裂都要记录旧结构的Undo，且分裂越深，Undo块数量呈指数增长。

• INSERT时，若目标叶块已满，Oracle需分配新块、移动部分键值、更新父节点指针，这些操作全部记Undo
• UPDATE索引键值（比如order_no变更），相当于一次DELETE旧键 + INSERT新键，Undo量≈2倍单条记录
• DELETE操作更危险：Global索引里删一条记录，可能让整个叶块变空，触发合并（coalesce），Undo要记录合并前所有块状态

RAC环境下Global索引加剧远程Undo访问

Global索引树物理上只存于一个实例的Buffer Cache中，其他实例修改数据时，必须通过Cache Fusion把索引块拉过来——这不仅产生大量CR（Consistent Read）请求，还会强制生成远程Undo段，跨实例一致性读失败时反复重试，Undo空间被重复占用。

• 序列cache_size太小（如cache_size ）或<code>order_flag = 'Y'，导致ID单调递增，所有新行挤在同一个索引叶块，RAC下该块成为热块，远程争用直接推高Undo远程访问压力
• 应用未使用/*+ APPEND */或ATOMIC_REFRESH => FALSE，INSERT走常规路径，每个row都要单独写索引，Undo生成频次翻倍
• Global索引建在非分区键列（如user_id）上，而查询又常按时间范围过滤，优化器误判走索引，实际执行时扫描整棵B-tree，Undo在后台默默积累却无人察觉

建索引期间Undo暴增不是临时现象，而是设计冲突

在业务高峰期执行CREATE INDEX ... GLOBAL，不是“慢一点”，而是让每个正在运行的DML都多扛一份索引维护开销。Oracle必须为每条变更同时更新数据段和全局索引段，IO和CPU双压，Undo生成速率远超回收能力。

• NOLOGGING能跳过Redo，但Undo照常生成——它保障的是回滚能力，和Redo无关
• 即使加PARALLEL 4，也只是加速索引构建本身，DML事务仍需同步维护索引，Undo压力不减反增
• PostgreSQL没有原生Global Index，靠BRIN或应用层模拟，但一旦强行用唯一约束+触发器模拟，Undo（或WAL）压力同样不可控

真正卡住Undo的，往往不是空间大小，而是Global索引把本来可以分散的写压力，强行收束成单点瓶颈——它不声不响，直到ORA-30036报出来才暴露。