RAC环境下gc buffer busy飙升主因是多实例并发写入同一热点分区块，而非锁争用；须采用2的幂次哈希子分区数（如4/8/16/32）、热冷分区物理隔离至不同表空间、本地索引严格对齐并显式指定表空间。
为什么RAC环境下gc buffer busy会飙升
这不是锁争用，而是多个实例同时往同一组热点分区的数据块和索引叶块写入，触发频繁的全局缓存（GC）块传输。尤其当所有新数据都落在最新分区（比如P_202607），且没做实例级写入隔离时，所有节点都在抢同一段物理块，gc buffer busy acquire等待直线上升。
子分区扩容必须是2的幂次倍数
哈希子分区数不是随便设的——SUBPARTITIONS 6这种写法在后续扩容时会直接卡死。因为Oracle哈希映射依赖模运算，从8→9会破坏原有散列分布，强制全量重分布；而8→16、16→32则能复用原有映射关系，只需局部迁移。
- 建表时子分区数只能选
4、8、16或32 - 扩容必须用
ALTER TABLE ... SPLIT SUBPARTITION，不能改SUBPARTITIONS参数 - 验证分布：查
SELECT subpartition_name, num_rows FROM dba_tab_subpartitions WHERE table_name = 'T'，各子分区行数偏差超15%即存在倾斜
冷热分区要物理隔离，不能只靠逻辑命名
把P_202601标为“冷分区”没用，真正起作用的是表空间绑定。如果所有分区都放在同一个ts_default里，I/O还是挤在一起。
- 热分区（近12个月）用高性能SSD表空间，如
ts_hot - 冷分区（12个月前）单独挂载到大容量SATA盘表空间，如
ts_cold - 创建时显式指定：
PARTITION p202601 VALUES LESS THAN (TO_DATE('2026-08-01', 'YYYY-MM-DD')) TABLESPACE ts_hot
本地索引必须按分区对齐，否则裁剪失效
本地索引（LOCAL）不是性能银弹——如果索引分区没和表分区严格一一对应，优化器就无法跳过无关分区，查询仍会扫描全部索引段。
- 建索引时必须带
LOCAL关键字，且不指定GLOBAL - 每个分区索引应独立指定表空间，例如：
PARTITION p202601 TABLESPACE idx_hot - 避免用
CREATE INDEX ... ON table(col) LOCAL省略分区定义，这会让所有索引分区默认落在用户默认表空间，失去I/O隔离意义
