INDEX SKIP SCAN和INDEX FULL SCAN

最新推荐文章于 2025-03-21 16:44:28 发布
最新推荐文章于 2025-03-21 16:44:28 发布
阅读量4k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： Oracle
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lemontree1123/article/details/8146936
本文深入探讨了数据库中的索引扫描技术，包括跳跃式索引扫描和全索引扫描的概念及应用场景，并通过实例演示了如何利用这些技术提升查询性能。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

INDEX SKIP SCAN:跳跃式索引能够通过使用非前缀列提高索引的查询性能.通常情况下,扫描索引块比扫描表数据块快.
跳跃式索引能够使复合索引逻辑上拆分分一个个小的子索引.在跳跃式扫描中,复合索引的首列不会被限定在查询中,因为它是跳跃式的.
数据库确定了一定数量的逻辑子索引通过在首列的去重的值中.当数据库中复合索引的前导列有很少的去重的值和索引中有非前导列有很多重复的值时跳跃式扫描就会有很多优点.
当复合索引的前导列没有被查询谓词界定时,数据库会选择跳跃式索引.

INDEX FULL SCAN:索引全扫描会排除排序操作,因为数据已经被按索引键值排序.读数据块是逐个读的.数据库在如下任何一个情况时可能会使用full scan:
An ORDER BY clause that meets the following requirements is present in the query(有order by子句存在于查询中):
All of the columns in the ORDER BY clause must be in the index.(在order by中的所有列必须被索引)
The order of the columns in the ORDER BY clause must match the order of the leading index columns.(在order by子句中排序的列必须匹配排序的前导列)
The ORDER BY clause can contain all of the columns in the index or a subset of the columns in the index.(order by子句中包含在索引中的所有列或者索引列的一个子集)

举例:

SESSION1:
SQL> create table  emp5 as select * from emp;

Table created.

SQL> create index skip1 on emp5(job,empno);

Index created.

SQL> commit;

Commit complete.

SQL> set autotrace traceon exp stat;
SQL> select count(*) from emp5 where empno=7900;


Execution Plan
----------------------------------------------------------
Plan hash value: 853491148

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |    13 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |       |     1 |    13 |            |          |
|*  2 |   INDEX FULL SCAN| SKIP1 |     1 |    13 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7900)
       filter("EMPNO"=7900)

Note
-----
   - dynamic sampling used for this statement (level=2) -------此处为动态信息采集,因为表没有被分析.


Statistics
----------------------------------------------------------
          5  recursive calls
          0  db block gets
          6  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
----------可以看出新建表在没有被分析的情况下,默认是走INDEX FULL SCAN.
----------此时再开一个session2,执行如下的查询:
SESSION2:
SQL> set autotrace traceon exp stat;
SQL> set serveroutput on
SQL> select /*+ index_ss(emp5 skip1) */ count(*) from  emp5 where empno=7900;-----此处加hint强制走index skip scan,和上面的index full scan形成对比


Execution Plan
----------------------------------------------------------
Plan hash value: 3156092949

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |    13 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |       |     1 |    13 |            |          |
|*  2 |   INDEX SKIP SCAN| SKIP1 |     1 |    13 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7900)
       filter("EMPNO"=7900)

Note
-----
   - dynamic sampling used for this statement (level=2)  -----因为表没有被分析,索引此处也是动态信息采集


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
          6  consistent gets
          0  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
-------此时看不出具体的区别,因为表很小,并且已经被缓存到SGA中.在session2中再执行以下操作:
SQL> alter system flush buffer_cache;

System altered.

SQL> alter system flush shared_pool;

System altered.

SQL> select /*+ index_ss(emp5 skip1) */ count(*) from  emp5 where empno=7900;


Execution Plan
----------------------------------------------------------
Plan hash value: 3156092949

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |    13 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |       |     1 |    13 |            |          |
|*  2 |   INDEX SKIP SCAN| SKIP1 |     1 |    13 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7900)
       filter("EMPNO"=7900)

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
         62  recursive calls
          0  db block gets
         56  consistent gets
         15  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed
-------在SESSION1也执行以下操作,确保不受缓存的影响:
SQL> alter system flush buffer_cache;

System altered.

SQL> alter system flush shared_pool;

System altered.

SQL> select count(*) from emp5 where empno=7900;


Execution Plan
----------------------------------------------------------
Plan hash value: 853491148

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |    13 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |       |     1 |    13 |            |          |
|*  2 |   INDEX FULL SCAN| SKIP1 |     1 |    13 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7900)
       filter("EMPNO"=7900)

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
         62  recursive calls
          0  db block gets
         56  consistent gets
         17  physical reads   ----------------此时可以看出微小的区别,即跳跃式索引产生的物理读比索引全扫描产生的物理读小.
          0  redo size
        526  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed

----------在SESSION1中分析这个表,再次看分析后的执行计划:
SQL> analyze table emp5 compute statistics;

Table analyzed.

SQL> alter system flush shared_pool;

System altered.

SQL> alter system flush buffer_cache;

System altered.

SQL> select count(*) from emp5 where empno=7900;


Execution Plan
----------------------------------------------------------
Plan hash value: 3156092949

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |     3 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |       |     1 |     3 |            |          |
|*  2 |   INDEX SKIP SCAN| SKIP1 |     1 |     3 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7900)
       filter("EMPNO"=7900)


Statistics
----------------------------------------------------------
         27  recursive calls
          0  db block gets
         50  consistent gets
         15  physical reads
          0  redo size
        526  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed
-------------可见分析过后,对于复合索引SKIP1,前导列没有在where的条件下的情况,数据库会自动选择INDEX SKIP SCAN.

-------------在SESSION2中,执行以下操作,看具体区别:
SQL> alter system flush buffer_cache;

System altered.

SQL> alter system flush shared_pool;

System altered.

SQL> select /*+ index_ss(emp5 skip1) */ count(*) from  emp5 where empno=7900;


Execution Plan
----------------------------------------------------------
Plan hash value: 3156092949

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |     3 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |       |     1 |     3 |            |          |
|*  2 |   INDEX SKIP SCAN| SKIP1 |     1 |     3 |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7900)
       filter("EMPNO"=7900)


Statistics
----------------------------------------------------------
         27  recursive calls
          0  db block gets
         50  consistent gets
         11  physical reads  -------------------此处少了一些,应该是缓存的游标或者在LRU的热端,导致少了一些物理读
          0  redo size
        526  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed
总结:最好把表分析过后,刷新缓存,这样做实验才有意义.如果走动态采样,可以执行hint看区别.
索引跳跃式扫描可以允许优化器使用组合索引，即便索引的前导列没有出现在WHERE子句中。索引跳跃式扫描比全索引扫描要快的多



index full scan/index fast full scan以及B+树索引
kevin_linshaojie的博客
02-11 1618
index full scan/index fast full scan以及B+树索引了解index full scan/index fast full scan的读取方式与顺序Oracle BTREE索引创建一般性经验(主要是前3条)以下步骤与信息供参考:index full scan运行并10046 trace记录，可见是按照index tree来进行访问的，以单个索引块访问为主index fast full scan的10046 trace，可见是以dba_extents的顺序进行全索引扫描的，以多块
mysql索引跳跃扫描_MySQL 8.0 之索引跳跃扫描(Index Skip Scan)
weixin_30249465的博客
01-18 420
前言MySQL 8.0.13开始支持 index skip scan 也即索引跳跃扫描。该优化方式支持那些SQL在不符合组合索引最左前缀的原则的情况，优化器依然能组使用组合索引。talk is cheap ，show me the code实践使用官方文档的例子，构造数据mysql> CREATE TABLE t1 (f1 INT NOT NULL, f2 INT NOT NULL, PRI...
INDEX FAST FULL SCAN AND SKIP SCAN
数据库
04-24 179
在快速扫描索引时，oracle读取b-tree索引的所有叶子节点块，而且是顺序读，而且可以同时读取db_file_multiblock_read_count, 而且索引快速扫描比full table scan的物理IO小很多，可以更快的响应请求。以下还是看下原文： The fast full scan can be used if all of the columns in the query...
index skip scan
blockheading的博客
11-01 362
--index skip scan --An index scan occurs in which the initial column of a composite index is "skipped" or not specified in the query. For example, if the composite index key is (cust_gender,cust_emai
mysql索引跳跃式扫描_索引跳跃式扫描（INDEX SKIP SCAN）
weixin_42303003的博客
02-19 407
索引跳跃式扫描(INDEX SKIP SCAN)索引跳跃式扫描(INDEX SKIP SCAN)适用于所有类型的复合B树索引(包括唯一性索引和非唯一性索引)，它使那些在where条件中没有对目标索引的前导列指定查询条件但同时又对该 索引的非前导列指定了查询条件的目标SQL依然可以用上该索引，这就像是在扫描该索引时跳过了它的前导列，直接从该索引的非前导列开始扫描一样(实际的执行过程并非如此)，这也是...
什么是INDEX SKIP SCAN
cjlt30472的博客
08-09 506
在查看SQL的执行计划的时候，有时候会看到INDEX SKIP SCAN，其实这个索引扫描路径会发生在多个列建立的复合索引上，如果SQL中谓词条件只包含索引中的部分列，并且这些列不是建立索引时的第一列时，就可 能发生INDE...
Index Skip Scan
lltfjsy的博客
03-21 855
Index Skip Scan
INDEX SKIP SCAN
cll3830995的博客
09-02 515
1.交待一下背景：交易明细表，18亿条数据，表的容量大小是：数据量有480G，联合主键索引是112G。联合主键索引是这样建立的： 点击(此处)折叠或打开 ...
关于INDEX SKIP SCAN
cizhe8562的博客
12-28 139
INDEX SKIP SCAN是9i之后提供的新功能，实现了即使WHERE条件中不存在索引的前导列也可以使用索引。但是INDEX SKIP SCAN是需要下面几个条件的：1，版本9i及以后2，CBO（表和索引都经过分析）3，索引...
Oracle CBO优化模式中的5种索引访问方法浅析
01-19
本文主要讨论以下几种索引访问方法： 1.索引唯一扫描(INDEX UNIQUE SCAN) 2.索引范围扫描(INDEX RANGE SCAN) 3.索引全扫描(INDEX FULL SCAN) 4.索引跳跃扫描(INDEX SKIP SCAN) 5.索引快速全扫描(INDEX FAST FULL SCAN) 索引唯一扫描(INDEX UNIQUE SCAN) 通过这种索引访问数据的特点是对于某个特定的值只返回一行数据，通常如果在查询谓语中使用UNIQE和PRIMARY KEY索引的列作为条件的时候会选用这种扫描；访问的高度总是索引的高度加一，除了某些特殊的情况，如另外存储的LOB对象。 代
索引跳跃式扫描（INDEX SKIP SCAN）
凉茶微凉
03-31 1937
执行计划中存在索引跳扫步骤 存在索引跳扫说明查询条件和索引定义不严格匹配 对于组合索引来说，在oracle8i之前，如果where字句中没有组合索引的前导列(即建立索引时排在第一位的字段)的话，这个组合索引在SQL语句中是不起任何作用的，在oracle9i中引入了跳跃式扫描，也就是如果在where字句中没有前导列的话也可以使用组合索引后面的列进行索引扫描，条件就是前导列的distinct的值不能...
Index Skip Scan 介绍
余璜的技术博客
10-07 1061
这种扫描方式就叫做 Index Skip Scan，之所以如此命名，是因为： - “Index”：因为 Index 具备数据有序存储的特征 - “Skip” ：二分的方式来跳着查找，所以是 skip - “Scan”：这个技术背后的本质目的还是扫描出需要的所有数据，所以还是 Scan 除了求 distinct 值，Index Skip Scan 还可以用于多种场景：
通过案例学调优之--Index FULL SCAN和Index FAST FULL SCAN
weixin_34146805的博客
11-24 290
通过案例学调优之--Index FULL SCAN和Index FAST FULL SCANIndex FULL SCAN和ndex FAST FULL SCAN工作原理： Index FULL SCAN 和Index FAST FULL SCAN的适用情况：适用于我们想选择的列都包含在索引里边时，这时候就可以使用IFS或者FFS来代替全表扫描来得到想要的结果。...
【优化】INDEX FULL SCAN (MIN/MAX)访问路径
cuanchuwei1207的博客
11-26 751
Oracle对单独使用max或min函数时给出了一种非常高效的访问路径，就是“INDEX FULL SCAN (MIN/MAX)”，该方法可以避免索引的全部读取，进一步提高数据结果的获取效率。通过这...
INDEX FULL SCAN vs INDEX FAST FULL SCAN
anjichan4261的博客
04-12 380
INDEX FULL SCAN 与 INDEX FAST FULL SCAN两个长相差不多，乃是一母同胞，因此既有其共性，也有其个性。两者来说其共性是不用扫描表而是通过索引就可以直接返回所需要的所有数据。这对提高查询性能而言，无疑是一个难得的数据访问方式之一，因为索引中存储的数据通常是远小于原始表的数据。下面具体来看看两者之间的异同。一、何时INDEX FULL SCAN 或...
ORACLE:INDEX FULL SCAN--99%是最烂的执行计划
Super菜的专栏
06-29 4779
原sql： SELECT * FROM ( SELECT c.id, c.username, c.keyword, c.batchid, i.bc_id, c.title, i.check
oracle full table scan,通过案例学调优之--Index FULL SCAN和Index FAST FULL SCAN
weixin_34226447的博客
04-05 1155
通过案例学调优之--Index FULL SCAN和Index FAST FULL SCANIndex FULL SCAN和ndex FAST FULL SCAN工作原理：Index FULL SCAN 和Index FAST FULL SCAN的适用情况：适用于我们想选择的列都包含在索引里边时，这时候就可以使用IFS或者FFS来代替全表扫描来得到想要的结果。INDEX FULL SCAN：HI...
高通camx ：full sweep 得到的lens pos和 single search table的index是什么关系
最新发布
06-19
<think>我们正在处理一个关于高通CAMX中镜头位置和搜索表索引关系的问题用户问题：我想了解高通CAMX中fullsweep得到的lenspos与singlesearchtableindex之间的关系根据之前提供的引用片段（尽管看起来是关于AF收敛的一些参数），可能与自动对焦（AF）的算法有关，但具体到fullsweep和singlesearchtableindex的关系，引用中并没有直接说明。因此，我们需要基于对自动对焦原理和高通CAMX架构的理解来回答。在自动对焦中，fullsweep（全扫描）通常是指镜头在整个对焦范围内移动，以找到最佳对焦位置。而singlesearch可能是指针对某个特定区域的搜索。在高通CAMX架构中，AF算法可能会使用一个搜索表（searchtable）来存储镜头位置（lensposition）与图像质量评估值（例如清晰度得分）的对应关系。这个表可能是一个数组，索引（index）对应着搜索步骤，而值则是镜头位置。fullsweep过程：1.镜头从最小位置到最大位置（或反之）以一定的步长移动。2.在每个步长处，计算图像清晰度得分（如梯度值、对比度等）。3.记录每个位置（lenspos）的得分，形成一条清晰度曲线。4.然后通过算法（如寻找峰值）确定最佳对焦位置。在fullsweep过程中，我们可能会得到一个数组，其中索引（index）是扫描步骤（0,1,2,...），而数组元素是对应的镜头位置（lensposition）。这个数组就是fullsweep的搜索表。singlesearchtableindex则可能是指在单次搜索中使用的索引。在AF收敛过程中，可能不需要每次都进行全扫描，而是基于之前的扫描结果或预测，在某个小范围内进行搜索（finesearch）。此时，singlesearchtable可能是一个更小的表，索引对应着这个小范围内的步骤。关系：-fullsweep得到的lenspos数组通常是覆盖整个对焦范围的，而singlesearchtableindex可能是基于fullsweep的结果，在最佳位置附近进行精细搜索时使用的索引。-在fullsweep之后，AF算法会确定一个粗略的最佳位置，然后在该位置附近进行单次搜索（finesearch）。这个精细搜索的范围和步长可能由参数控制（如引用中提到的MinFineScanRange,FineScanStepSize等）。-因此，singlesearchtableindex可能是在fullsweep得到的搜索表的基础上，截取一段（比如最佳位置附近）并重新索引，或者使用不同的步长生成一个新的小表。注意：具体实现可能因平台和算法不同而有所差异。由于我们没有直接相关的引用，这里基于一般原理进行解释。为了更准确，我们可以参考高通CAMX的文档或源码，但在此我们只能根据常见做法推理。回答结构：1.解释fullsweep过程2.解释singlesearchtableindex的概念3.说明两者之间的关系4.可能涉及的参数（如引用中提到的参数）如何影响这个关系生成相关问题：根据这个主题，生成几个相关问题。注意：使用中文回答，数学表达式用$...$或$$...$$。</think>### 高通CAMX中Full Sweep与Single Search Table Index的关系 在高通CAMX的自动对焦（AF）算法中，`full sweep`（全扫描）和`single search table index`（单次搜索表索引）的关系如下： 1. **Full Sweep的作用** 全扫描会遍历整个镜头位置范围（Lens Position Range），生成一个**清晰度得分曲线**。该过程记录每个镜头位置（如从0到1023步进）对应的图像清晰度值（如梯度数据），形成原始对焦数据表[^1]。 2. **Single Search Table的生成** Full Sweep完成后，系统会对原始数据进行处理： - **降噪处理**：通过`noise_multiplier`参数过滤无效波动 - **峰值检测**：识别清晰度曲线的局部最大值 - **索引映射**：将有效的镜头位置重新编号，生成优化后的`single search table`，其索引（Index）与镜头位置（Lens Pos）存在映射关系： $$ \text{Index}_n = f(\text{LensPos}_n, \ \text{noise\_multiplier}, \ \text{FineScanStep}) $$ 其中$n$是重新排序后的新索引。 3. **关键参数影响** - `Min Fine Scan Range`：决定单次搜索的最小范围阈值 - `Fine Scan Step Size`：控制索引对应的镜头位置步长 - `Focus Done Threshold`：结合`dof_multiplier * noise_multiplier`判断索引有效性 4. **实际工作流程** ```mermaid graph LR A[Full Sweep] --> B[原始Lens Pos数据] B --> C[降噪与峰值提取] C --> D[生成Single Search Table] D --> E[按Index执行精细搜索] ``` > **总结关系**：Full Sweep得到的镜头位置是**原始物理值**，而Single Search Table Index是**优化后的逻辑索引**。后者通过算法将物理位置重新排序，排除噪声干扰，使后续精细搜索（如`Enable Fine Scan`）更高效[^1]。 --- ### 相关问题 1. Full Sweep过程中如何确定镜头移动的步长精度？ 2. `noise_multiplier`参数如何影响Single Search Table的生成？ 3. 在精细搜索阶段，索引与镜头位置的映射关系是否会动态调整？ 4. CAMX中哪些模块负责管理Lens Pos与Search Table的转换？ [^1]: 参数说明参考CAMX AF收敛算法文档：`Conv Frame Skip`控制扫描帧间隔，`Min Fine Scan Range`定义有效搜索阈值，`Focus Done Threshold`需结合噪声参数验证对焦完成状态。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值