《Pro Oracle SQL》Chapter3--3.2.6 Index Skip Scan

Index Skip Scan    索引跳跃扫描     (page 107)
    An index skip scan is chosen when the predicate contains a condition on a non-leading column in an
index and the leading columns are fairly distinct .   In earlier releases of Oracle, if a predicate used a
column that wasn’t the leading column in an index, the index couldn’t be chosen.  This behavior
changed in Oracle version 9 with the introduction of the index skip scan .  A skip scan works by logically
splitting a multi-column index into smaller subindexes.  The number of logical subindexes is
determined by the number of distinct values in the leading columns of the index.  Therefore, the more
distinct the leading columns are, the more logical subindexes would need to be created.   If too many
subindexes would be required, the operation won’t be as efficient as simply doing a full scan.  
However, in the cases where the number of subindexes needed would be smaller, the operation can be
many times more efficient than a full scan as scanning smaller index blocks can be more efficient
than scanning larger table blocks. Listing 3-15 shows an example of an index skip scan plan (Note: For
this example, I used a copy of the hr.employees table which had nearly 28,000 rows).
    当谓词包含的条件(作用)在索引的非前置列上而前置列却十分明显 时，索引跳跃扫描将被选择。 在Oracle的早期版本中，如果谓词使用了索引的非前置列， 索引就不会被选择。该行为随着Oracle 9引入了索引跳跃扫描而改变了。跳跃扫描原理是，把多列索引逻辑划分成小的子索引。逻辑子索引的数量由索引前置列的明显值的个数确定。因此，前置列越 明显，就会创建越多的逻辑子索引。 如果需要创建的逻辑子索引太多，操作的效率可能还比不上直接做全扫描。然而，如果所需的子索引的数量较小，操作的效率将数倍于全扫描，因为扫描较小(范围)的索引块比扫描较大表块更有效率。列表3-15展示了一个索引跳跃扫描的例子(注意：本例中，我使用了 hr.employees表的一备份表有将近28,000行)。
Listing 3-15. Index Skip Scan Examples
SQL> create index emp_jobfname_ix on employees(job_id, first_name, salary);   
 --这里job_id就是前置列
Index created.
 
SQL> set autotrace traceonly 
SQL>
SQL> select * from employees where first_name = 'William';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3440948136
 
------------------------------------------------------------------------------------
| Id  | Operation                                        | Name                        | Rows  | Bytes | Cost (%CPU)|
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                                  |     1 |    82 |    21   (0)|
|   1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEES             |     1 |    82 |    21   (0)|
|*  2 |   INDEX SKIP SCAN                        | EMP_JOBFNAME_IX |     1 |         |    20   (0)|
------------------------------------------------------------------------------------
 Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("FIRST_NAME"='William')
       filter("FIRST_NAME"='William')
 
Statistics
-------------------------------------------------------
          0  recursive calls
          0  db block gets
         50  consistent gets
          0  physical reads
          0  redo size
       2362  bytes sent via SQL*Net to client
        392  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         23  rows processed
 
SQL> select /*+ full(employees) */ * from employees where first_name = 'William';
 
23 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1445457117
 
-------------------------------------------------------------------------------
| Id  | Operation                       | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                      |     1 |    82 |    84   (2)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL  | EMPLOYEES     |     1 |    82 |    84   (2)| 00:00:02 |
-------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("FIRST_NAME"='William')
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        376  consistent gets
          0  physical reads
          0  redo size
       2735  bytes sent via SQL*Net to client
        392  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         23  rows processed
 
SQL> -- How many distinct values of job_id?
SQL> select count(distinct job_id) ct from employees ;
 
             CT
---------------
             19
    In this example, the leading column of the index,  job_id, has 19 distinct values.  Using an index
skip scan to access the 23 rows that match the condition (first_name = ‘William’), there are 50
consistent gets (logical block accesses).  However, if a full table scan is used, 376 blocks are accessed. 
As you can see, the skip scan is much more efficient.  What happened was that the index was logically
divided into 19 subindexes and each subindex was scanned for a match for first_name = ‘William’. 
For this index scan type, just keep in mind that the fewer distinct values the leading column (or
columns) have, the fewer logical subindexes will be needed and therefore the fewer total block
accesses required.   
    在例中，索引的前导列，job_id，有19个明显值。使用索引跳跃扫描访问匹配条件(first_name='William')的23行(记录),用了50个一致读 (逻辑块访问)。然而，如果使用全表扫描，就要访问376个块。如你所见，跳跃扫描有效率多了。索引逻辑上划分成19个子索引且扫描每个子索引匹配first_name='William'。对于这种扫描类型，只要记住前置列(或列集)的明显值越少，所需的逻辑子索引越少，则因此所要访问的总块数越少。