IndexScan 使用索引来确定哪些行满足搜索条件。索引扫描在访问表之前帮助减少符合条件的行集。索引扫描还可以将行按排序的顺序返回。

IndexScan 在简要计划中显示为 correlation-name<index-name>，其中 correlation-name 是在 FROM 子句中指定的相关名（如果未指定相关名，则为表名），index-name 是索引的名称。

索引为读取大表中的少数行提供了高效的机制。但是，在从表读取许多行时，索引扫描比顺序扫描开销更大。索引扫描从数据库中读取页的顺序是随机的，这种方法所占用的资源比按顺序读取所占用的资源多。如果页上有多行满足搜索条件，索引扫描还可以多次引用同一表页。如果索引扫描仅匹配少数几页，这些页很可能会留在高速缓存中，而多次访问不会导致额外的 I/O。但是，如果有多页匹配搜索条件，它们可能无法全部装入高速缓存。这会使索引扫描从磁盘中多次读取同一页。

如果搜索条件具有 sargable 特性，并且优化程序对搜索条件选择性的估计值较小，使索引扫描的开销低于顺序表扫描的开销，则优化程序将使用索引扫描来满足搜索条件。

索引扫描也可以在从索引读取行之后计算非可优化搜索条件。在索引扫描中计算条件比在索引扫描之后在过滤器中进行计算要略为有效。

即使没有要满足的搜索条件，索引也可用于满足在 ORDER BY 子句中显式定义或者在 GROUP BY 或 DISTINCT 子句中隐式需要的排序要求。与基于散列的分组和非重复方法相比，带 GROUP BY 和 DISTINCT 的排序方法可以更快地返回初始行，但它们在返回整个结果集时的速度可能较慢。

如果 optimization_goal 设置为 first-row，则优化程序往往会优先使用索引扫描而非顺序表扫描。这是因为索引扫描会比表扫描更快地返回查询的前几行。

在编写查询时，可以指定索引提示来告知优化程序要使用哪些索引及如何使用它们。但是，索引提示会替换查询优化程序的决策逻辑，因此只应由经验丰富的用户使用。使用索引提示可能会导致访问计划达不到最优，并会导致性能较差。请参见FROM 子句。