Oracle分区索引深度解析：本地与全局索引原理及选型指南

分区索引，简而言之，就是将一个大型索引拆分为多个物理片段。通过这种划分，数据库能够访问更小、更快的索引片段，并且可以将这些片段分布到不同的磁盘驱动器上，从而有效避免 I/O 竞争。B 树索引和位图索引都可以进行分区，而哈希索引则不支持。分区有多种组合方式：表分区而索引未分区、表未分区而索引分区，或者表和索引都分区。无论采用哪种方式，都必须启用基于成本的优化器。分区技术从多个维度为提升性能与可维护性提供了可能。

分区索引主要分为两种类型：本地索引和全局索引。每种类型又可以根据是否包含分区键的前导列，细分为有前缀索引和无前缀索引。一个表可以在其列上创建任意数量的、各种类型的索引。如果使用了位图索引，则必须是本地索引。对索引进行分区最主要的好处在于减少每次查询需要读取的索引数据量。此外，将不同分区放置在不同的表空间中，还能进一步提高数据的可用性和可靠性。

Oracle 还支持在分区的表和索引上执行并行查询与并行 DML 操作。这意味着可以启动多个进程同时处理一条语句，从而显著加速整体处理速度。

1. 本地索引（最常用）

本地索引，是指与分区表使用相同的分区键和范围界限的索引。它的每个分区只包含对应表分区中的键值和 ROWID。本地索引可以是 B 树索引，也可以是位图索引。如果是 B 树索引，则既可以是唯一的，也可以是非唯一的。

这类索引的最大优势在于支持分区独立性。这意味着对于单独的表分区，我们可以进行添加、截断、删除、分割、脱机等维护操作，而无需删除或重建整个索引。Oracle 会自动维护这些本地索引。甚至，单个本地索引分区也可以被独立重建，其他分区完全不受影响。

有前缀索引

有前缀索引是指包含分区键，并且将分区键作为索引前导列的索引。

举个例子，假设我们有一个按 survey_id 和 survey_date 列进行范围分区的 participant 表。如果我们在 survey_id 列上创建一个本地索引，那么这个索引就是本地的有前缀索引，如下图所示。此时，索引的所有分区都与表的分区“对等划分”，即它们使用与表完全相同的范围界限来创建。

图1：分区的有前缀索引

关键点： 本地的有前缀索引允许 Oracle 的查询优化器快速“剪裁”掉不相关的分区。也就是说，在 WHERE 条件子句中未涉及到的任何值的分区将不会被访问，这能极大提升查询性能。

无前缀索引

无前缀索引则是指，没有将分区键的前导列作为索引前导列的索引。

还是使用那个按 survey_id 和 survey_date 分区的 participant 表。如果我们在 survey_date 列上创建一个索引（注意 survey_date 是分区键的第二列），那么这个索引就是本地的无前缀索引，如下图所示。你可以在表的任何列上创建本地的无前缀索引，但每个索引分区仍然只包含对应表分区的键值。

图2：分区的无前缀索引

这里有一个重要限制：如果要将无前缀索引创建为唯一索引，那么该索引必须包含分区键的子集。 在上面这个例子中，你就需要创建一个包含 survey_date 和/或 survey_id 的组合索引（只要 survey_id 不是索引的第一列，否则它就又变成有前缀索引了）。

关键点： 对于唯一的无前缀索引，它必须包含分区键的子集。

2. 全局索引

全局索引与本地索引不同，它的一个索引分区中可能包含来自多个表分区的键值。全局索引的分区方式（分区键或分区范围）与底层表的分区方式是不同的。在创建时，你必须明确指定其分区键的范围和值。全局索引只能是 B 树索引。

默认情况下，Oracle 不会自动维护全局索引。 当你对表分区执行截断、添加、分割、删除等修改操作时，如果没有在 ALTER TABLE 命令中指定 UPDATE GLOBAL INDEXES 子句，那么之后就必须手动重建受影响的全局索引。

有前缀索引

通常情况下，全局的有前缀索引并不会采用与底层表对等的分区方式。虽然技术上可以创建对等分区的全局有前缀索引，但 Oracle 的查询优化器在执行查询计划或分区维护操作时，并不会充分利用这种对等分区带来的优势。如果索引确实需要与表对等分区，正确的做法是将其创建为本地索引，这样 Oracle 既能自动维护，又能利用它进行分区剪裁。

下图展示了一个全局的有前缀索引，它的三个索引分区各自包含了指向多个表分区中行的索引条目。

图3：分区的全局有前缀索引

无前缀索引

Oracle 不支持全局的无前缀索引。因为与建立在相同列上的普通 B 树索引相比，全局无前缀索引没有任何性能或管理上的优势，因此没有支持的必要。

通过本文的梳理，希望你对 Oracle 中本地索引与全局索引的区别、以及有前缀与无前缀索引的应用场景有了更清晰的认识。在实际的数据库设计与优化中，根据业务查询模式和数据维护需求做出正确的索引选型至关重要。想了解更多后端架构与数据库的深度知识，欢迎来云栈社区交流探讨。