【每日一摩斯】-Index Skip Scan Feature (212391.1)

简介: INDEX Skip Scan,也就是索引快速扫描,一般是指谓词中不带复合索引第一列,但扫描索引块要快于扫描表的数据块,此时CBO会选择INDEX SS的方式。

INDEX Skip Scan,也就是索引快速扫描,一般是指谓词中不带复合索引第一列,但扫描索引块要快于扫描表的数据块,此时CBO会选择INDEX SS的方式。

官方讲的,这个概念也好理解,如果将复合索引看做是一个分区表,其中分区主键(这里指的是复合索引的首列)定义了存储于此的分区数据。在每个键(首列)下的每行数据都将按照此键排序。因此在SS,首列可以被跳过,非首列可以作为逻辑子索引访问。因此一个“正常”的索引访问可以忽略首列。

复合索引被逻辑地切分成更小的子索引。逻辑子索引的个数取决于初始列的cardinality。因此尽管首列未出现在谓词中,也可能使用这个索引。、

另外,需要吧补充一点:当复合索引的第一个字段的值重复率非常低时,扫描索引的效率会比全表扫描更高,这是CBO才可能会选择使用INDEX Skip Scan的方式访问数据。


这里比较奇怪的是:


使用9i时,未使用INDEX Skip Scan:

SQL> create table at2(a varchar2(3),b varchar2(10),c varchar2(5));
Table created.

SQL> begin
  2    for i in 1..1000
  3    loop
  4    insert into at2 values('M', i, 'M');
  5    insert into at2 values('F', i, 'F');
  6    end loop;
  7    end;
  8  /
PL/SQL procedure successfully completed.

SQL> create index at2_i on at2(a,b,c);
Index created.

SQL> exec dbms_stats.gather_table_stats(OWNNAME => NULL, TABNAME => 'at2', CASCADE => TRUE, method_opt => 'FOR ALL COLUMNS SIZE 1');
PL/SQL procedure successfully completed.


SQL> set autotrace traceonly


SQL> select * from at2 where b='352';
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=2 Bytes=14)
   1    0   INDEX (FAST FULL SCAN) OF 'AT2_I' (NON-UNIQUE) (Cost=2 Car
          d=2 Bytes=14)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         10  consistent gets
          0  physical reads
          0  redo size
        447  bytes sent via SQL*Net to client
        587  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          2  rows processed


使用10g的,则使用了INDEX Skip Scan:

SQL> select * from full_tbl where object_name='TEST';
Execution Plan
----------------------------------------------------------
Plan hash value: 1293869270
------------------------------------------------------------------------------
| Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |          |     2 |    58 |    55   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| FULL_TBL |     2 |    58 |    55   (2)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_NAME"='TEST')

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        230  consistent gets
          0  physical reads
          0  redo size
        585  bytes sent via SQL*Net to client
        492  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed


难道9i和10g在选择INDEX Skip Scan还有什么不同么?

目录
相关文章
|
6月前
|
机器学习/深度学习 人工智能
【CatBoost报错解决】CatBoostError: Bad value for num feature[non default doc idx=0,feature idx=19]=
【CatBoost报错解决】CatBoostError: Bad value for num feature[non default doc idx=0,feature idx=19]=
|
人工智能 数据库 索引
2020 SIGMOD:BinDex A Two-Layered Index for Fast and Robust Scan 笔记
目前的查询扫描主要归类为两种方法,一种是顺序扫描 如全表扫描,一种是通过索引扫描 如b-tree等。1. 顺序扫描可能需要访问大量的无用的数据,特别是当选择率低的时候。2. 索引扫描在选择率较高的时候,可能会导致大量的随机内存访问。这些都会导致性能的下降,所以在执行查询操作时,需要根据具体的查询情况(如选择率的高低),选择合适的方法(选择顺序扫描,还是索引扫描)用于查询。但随着数据库查询负载变得复杂,很难去选择合适的方法应对特定的查询(到底是选顺序扫描?还是索引扫描?)。 因此本文提出了一种新的索引方案—BinDex(后面简称BD),可在不同的选择率情况下,同样能够快速地进行查询。 BinDe
|
SQL Oracle 关系型数据库
【DB吐槽大会】第62期 - PG 不支持index skip scan
大家好,这里是DB吐槽大会,第62期 - PG 不支持index skip scan
|
SQL 索引 存储
Sql Server 聚集索引扫描 Scan Direction的两种方式------FORWARD 和 BACKWARD
原文:Sql Server 聚集索引扫描 Scan Direction的两种方式------FORWARD 和 BACKWARD 最近发现一个分页查询存储过程中的的一个SQL语句,当聚集索引列的排序方式不同的时候,效率差别达到数十倍,让我感到非常吃惊由此引发出来分页查询的情况下对大表做Cluster...
1401 0
|
SQL 移动开发 Oracle
optimizer_index_caching和optimizer_index_cost_adj两个参数说明
optimizer_index_caching和optimizer_index_cost_adj两个参数说明 OPTIMIZER_INDEX_COST_ADJ Property ...
1607 0