关于索引的使用模式(r3笔记56天)

jeanron100

发布于 2018-03-15 10:04:53

5370

发布于 2018-03-15 10:04:53

索引的使用对于一些庞大的sql语句来说，大多数的调优场景中有种雪中送炭的感觉，如果几百万,几千万的数据筛查，全表扫描将会是一个极度消耗资源的过程，但是如果走了索引扫描，可能性能会提升成百上千倍。索引的访问模式有以下几种，其实有些时候对有些细节还是不太注意。对不同的使用场景可以有一定的针对性，效率也许更高。可以创建如下的测试表来简单归纳一些。

SQL> create table a as select object_id,object_name,object_type from  dba_objects;
Table created.
SQL> desc a
 Name                                                   Null?    Type
 ----------------------------------------------------- --------  ------------------------------------
 OBJECT_ID                                                       NUMBER
 OBJECT_NAME                                                     VARCHAR2(128)
 OBJECT_TYPE                                                     VARCHAR2(19)
SQL> analyze table a compute statistics;
Table analyzed.
SQL> create unique index ind_a on a(object_id);  --我们创建了唯一性索引
Index  created.
SQL> set autot traceonly exp

查看执行计划，使用了index uniqe scan,这种方式是最快的索引访问模式。

我们只输出索引列的值，结果预想可以走索引扫描，但是结果走了全表扫描，来看看为什么。

我们只需要简单的修改一些列的属性，就可以排除null的干扰，走索引扫描，这个时候走的是快速索引全扫描。这种索引扫描因为不会涉及到排序，所以扫描要快一些。

如果要对索引列作排序，这个时候可以使用索引全扫描，通过下面的执行计划可以看到快速扫描和全扫描的差别。

如果涉及到索引列的区间值，可以使用区间扫描，比如我们常用的between条件就会走区间扫描。

对于跳跃索引扫描，可能会略微难懂一些。可以举一个简单的例子来模拟一下。我们创建一个表a，然后让一些字段的数据分布倾斜。

SQL>  drop index ind_a;
Index dropped.
SQL> create index ind_a on  a(object_type,object_id,object_name);
Index created.
SQL> analyze table  a compute statistics for all indexed columns;
Table analyzed.
SQL>  select object_id from a where object_type='INDEX PARTITION' and rownum<2;   --我们随便抽取出一条记录来做测试。Object_id为5639
 OBJECT_ID
----------
      5639

可以看到数据的分布情况如下。