一、你的查询完全可以利用分区优势 #

先给你吃个定心丸：你写的这个查询

select b.some_data from beta b where b.alpha_name = 'Blah' ;

完全足够触发分区裁剪，不需要关联父表alpha或者引入partition_no列。

原因很简单：参考分区的核心逻辑就是让子表beta的分区和父表alpha的分区严格对齐——每一条beta记录都会跟着它关联的alpha记录落在对应的分区里。当你用alpha_name = 'Blah'过滤时，Oracle会通过外键关系快速定位到alpha表中这条记录所在的分区，进而直接只扫描beta表中对应的那个分区，不会去碰其他数亿行的分区。

你可以通过查看执行计划验证这一点：执行计划里会出现类似PARTITION REFERENCE SINGLE的操作，说明Oracle确实做了分区裁剪，只访问了目标分区。

二、参考分区表的索引创建注意事项 #

针对你这种亿级数据的场景，索引创建有几个关键要点：

• 优先创建本地分区索引
  本地索引会和表的分区完全对齐，每个分区的索引只对应表的一个分区。这样一来，查询时会跟着表的分区裁剪一起裁剪索引，性能拉满；而且在维护分区（比如新增、合并分区）时，本地索引会自动同步维护，不会像全局索引那样变成UNUSABLE需要重建——这对亿级表来说太重要了，避免了大量的索引重建开销。

  比如针对你的查询场景，创建一个本地索引：

  create index idx_beta_alpha_name on beta(alpha_name) local;
  

  这个索引会完美配合你的alpha_name过滤查询，快速定位到目标分区内的记录。

• 谨慎使用全局索引
  除非你有频繁跨多个分区的查询需求，否则尽量不要创建全局索引。全局索引是跨所有分区的单一索引结构，不仅查询时无法有效利用分区裁剪，而且在对表做分区维护操作（比如ALTER TABLE ... ADD PARTITION）时，全局索引会直接失效，需要手动重建——对于数亿行的表，重建全局索引的时间和资源消耗都是巨大的。

• 主键/唯一索引的特殊处理
  你的beta表主键是name，默认创建的主键索引是全局的。如果业务允许，建议把alpha_name加入主键（比如primary key(name, alpha_name)），这样主键索引就可以创建成本地索引，既保证唯一性，又能享受分区带来的性能优势。如果不能修改主键，那至少要给alpha_name单独建一个本地索引，来支撑你的高频查询。

• 维护好分区级统计信息
  分区表的统计信息一定要细化到分区级别，Oracle才能根据每个分区的数据分布生成最优的执行计划。收集统计信息时记得指定GRANULARITY => 'ALL'：

  exec DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => '你的用户名', TABNAME => 'BETA', GRANULARITY => 'ALL');
  

内容的提问来源于stack exchange，提问作者Matt Knowles