Oracle分区表全局索引维护导致Undo压力过大的原因

Global索引和Undo暴涨之间的关联，很多人在线上踩过坑才后知后觉。简单来说，就是Global索引强制串行化了所有分区的写操作，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量大约是单条记录的两倍。 - DELETE操作更危险：Global索引里删一条记录，可能让整个叶块变空，触发合并（coalesce）。合并前所有块的状态都得记入Undo，量就上去了。 ### RAC环境下Global索引加剧远程Undo访问 Global索引树物理上只存在一个实例的Buffer Cache里。其他实例修改数据时，必须通过Cache Fusion把索引块拉过来——这不仅会产生大量CR（Consistent Read）请求，还会强制生成远程Undo段。一旦跨实例一致性读失败，反复重试，Undo空间就被重复占用，雪上加霜。 - 序列`cache_size`设太小（比如`cache_size < 20`），或者`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的，往往不是UNDO表空间的大小，而是Global索引把本来可以分散的写压力强行收束成单点瓶颈——它不声不响，直到`ORA-30036`报出来才暴露。