Oracle基本索引

1、Oracle基本索引概念当从表中读取数据时，Oracle提供了两个选择：从表中读取每一行（全表扫描）通过ROWID 次读取一行当我们要访问大型表的少数行时，可能需要使用索引。因为如果没有索引，那么只能进行全表扫描。索引改进性能的程度取决于两个因素：1数据的选择性2、表数据在数据块上的分布如果选择性很高（例如身份证号码），那么根据索引值返回的ROWID很少，如果选择性很低（例如国家）则返回的ROWID很多，那么索引的性能将会大大降低如果选择性很高，但是相关的行在表中的存储位置并不互相靠近，则会进一步减少索引的益处，如果匹配索引值的数据分散在表的多个数据块中，则必须从表中选择多个单独的块以满足查询

2、，基于索引的读取是单块读取，如果使用全表扫描，使用的是多块读取以快速扫描表，因此全表扫描不见得比索引扫描速度慢。不要迷信工具，每天学习一个视图，了解视图中常用列Oltp中使用B树索引重点掌握执行计划与索引的查找全表扫描性能不一定差，索引性能不一定好，代价是决定选择的依据索引建立步骤：首先将表中的一列取出来放进pga中的sort area区中排序，如果sort area不存在或不够就放在临时表空间中将排序得到列转化成树大多数排序都是在内存中进行的，但如果内存不够就使用磁盘进行排序，我们只希望最 多进行一次磁盘排序，多次磁盘排序影响性能我们可以将临时表空间临时性的扩大，这样排序空间加大，加快排序速

3、度 排序的目的是将相同的内容放在一起，不用全表扫描索引的性能高是因为索引体积小，只有一个列，可以cache到内存中索引访问总是访问的内存，做到这点就要求索引选择的列要窄Null在排序中不会产生对应的数值，因为列中允许存在一个null，就会有多个null，这些null不能对应回相应列中列值被删除，索引也会被删除，索引空间不会合并因为表是以块为单位的，可以被重复使用，表是无序的，只要尽可能的紧凑，但索引不 是，索引是有序的，不能插入，也不能整体上移，上移的代价很高。当删除的索引很多 时，索引就变空了，这时需要重建索引索引是一颗树，有树可以定位到块，实现快速定位索引的缺点：占用空间，占用内存每次查找

4、都要从根查找，每次查找一个节点都是一次io过程，最后还会有一次磁盘io的过程读取表对应的信息对dml影响大，表更新时索引也需要更新，他们是同步的 dml操作后，一定要同步索引，有索引的dml操作时间是无索引的3倍时间，因此索引的数量控制在6个内数据选择性：列的唯一性非常高Rowid :根据rowid定位基于数据文件的数据块的数据行，根据rowid找记录的速度最快调优不期望通过索引有多大的改善，通常是调表索引是有序的，进行范围索引时会得到一组rowid，比如5个。我们希望这 5个rowid落在一个数据块上，不希望落在5个块上在订单号和日期上建索引较好，日期函数除外，它不能建索引索引总是单块读，一

5、个挨着一个读，全表扫描是多块读，一次读多个块，索引性能很高 全表扫描有一个问题是当大的表读进内存中时，会冲刷小表全表扫描和索引查找之间的平衡点1分区2、并行DML3、并行查询4、使用 db_file_multiblock_read_count 进行更大的 10 操作5、硬件更为快速6、磁盘上的缓存可以缓存更多的数据7、内存的廉价使得我们的内存进一步增大8、Oracle采用了增强的索引特性（例如跳跃式扫描索引）SQL show parameter db_file_multiblock_read_co unt;NAMETYPEVALUEdb file multiblock read countin

6、teger8cbo优化器:sql语句作出多个执行计划，执行方案，使用性能最高并且性能影响最小，代价 最小的。这个代价是估算得到的，所以执行结果不一定准 确，它是根据表和索引的统计数据，统计数据在字典中。包括行数，块数，每一列的选择 性，不同的行的不同数值范围Cbo严重依赖统计数据，统计一定要正确，但不会影响结果，只是时间快慢的问题Rbo优化器：根据规则作出多个执行计划，由一个规则表，对sql进行比较。From a,b与fromb，a因为对应不同的规则，因此执行计划不同，因此sql语句写得漂亮指的就是 rbo在9i前可以选择rbo或cbo，在10g只有cbo,因为在10g时出现了调度和作业，调度

7、完成 计划任务，每天执行统计作业，收集统计数据。统计数据一定要准确的。统计操作是非常耗资源的，所以不一定扫表，可能是使用字典10g中还允许使用指定rbo。但初始化参数时已经没有rbo 了数据库迁移也要迁移统计数据 分区：多个分区在多个磁盘上，oracle自发的并发读Oracle倾向于全表扫描，因为全表扫描优于索引扫描，全表是并行读，索引是单块读 db_file_multiblock_read_count导致使用全表，默认一次读8个块。一个io读8个块，不要轻易调这个参数，会导致全表扫描所谓硬件就是指的存储设备建索引需要更多内存走全表扫描需要消耗更过io如果硬件快，物理10 cost低，走全表扫

8、描硬盘的缓存导致物理10性能提高，但对异步10在计算成本时产生误差 目前的智能技术不能算是成熟db_file_multiblock_read_cou nt的自动调整关于这个参数，经过几多变化，在Oracle10gR2中终于修成了正果，实现了自动调整。很久以前演过过这个参数，初始化参数db_file_multiblock_read_count 影响Oracle在执行全表扫描时一次读取的block的数量.db_file_multiblock_read_count的设置要受 OS最大10能力影响，也就是说，如果你系统的 硬件10能力有限，即使设置再大的db_file_multiblock_read_

9、count也是没有用的。理论上，最大 db_file_multiblock_read_count和系统10能力应该有如下关系：Max(db_file_multiblock_read_cou nt) = Max0sl0size/db_block_size当然这个 Max(db_file_multiblock_read_count)还要受 Oracle 的限制，目前 Oracle 所支持的最大 db_file_multiblock_read_count 值为 128.我们可以通过db_file_multiblock_read_count来测试Oracle在不同系统下，单次10最大所能读取得数据量这

10、个参数的设置可能影响到CBO优化器的执行计划选择，所以Oracle通常缺省设置为16,不推荐设置高于32的值。在Oracle10gR2以前的版本中，DBA必须根据db_block_size参数，以及应用系统的特性， 来调整 db_file_multiblock_read_count参数。该参数值将影响CBO在该产生何种 SQL执行计划上的判断。我们知道如下的公式，其中max I/O chunk size跟操作系统有关，但是Oracle文档中也指出大多数操作系统上该值为1M。 db_file_multiblock_read_count = max I/O chunk size /db_block

11、_size目前 Oracle 所支持的最大 db_file_multiblock_read_count 值为 128.1024K/8K=128在Oracle10gR2之后的版本(10gR2和11g)中，Oracle数据库已经可以根据系统的10能力以及Buffer Cache的大小来动态调整该参数值，Oracle建议不要显式设置该参数值。在我的一个11.1.0.7的环境中，这个值被自动调整为73:SQL select * from v$version;BANNEROracle Database 11g En terprise Edition Release 11.1.0.7.0 - Produc

12、tion PL/SQL Release 11.1.0.7.0 - Productio nCORE 11.1.0.7.0 ProductionTNS for Linux: Version 11.1.0.7.0 - ProductionNLSRTL Versio n 11.1.0.7.0 - ProductionSQL show parameter multiNAMETYPEVALUEdb_file_multiblock_read_co untin teger73parallel_adaptive_multi_userboolea nTRUESELECT、UPDATE、DELETE+WHERE 条

13、件可以从索弓I中得至収子处（前提是：当访问的行数较少时）一般来说，增加索引会带来insert语句性能的下降如果根据未索引列 update索引列，那么也会带来性能的降低大量的delete也会因为索引的存在而导致性能降低因此我们要分析具体的情况，判断索引和DML语句之间的关系有where条件时走索引，无 where条件时走全表扫描Insert走索引，因为使用了主键根据索引列update未索引列，性能高，update更新为索引列根据未索引列update索引列，既改变了索引列又改变了索引，性能低叶子块拆分：当update 一个索引列时，导致索引列重新排序，改变的记录可能被挤到了最后一条记录的 下面，此

14、时如果pct free已经满了，这个块将导致分裂，将原来放在一个块上的记录数据, 分成了 2个块。结果导致索引性能降低。这不属于行迁移不停的update导致pct free引发后果：1分配数据块，有等待事件2数据拷贝Insert和delete影响都不如 update影响大硬盘数据是以堆的方式保存的，通过链接穿起来。拆分就是又增加了一个块，建立链接，是内容被拆分了我们如何去去判断一个表上的索引呢？SQL create table a.a as select * from dba_objects;表已创建。SQL create in dex a.idx_a on a.a(object_id);索引

15、已创建。SQL select table_ name,i ndex_ name from dba_ in dexes where table_ name=A：INDEX NAMETABLE NAMESQL col table_ name format a5;SQL col in dex_ name format a5;SQL col colu mn_n ame format a10;SQL select table _n ame,i ndex_ name,colu mn_n ame,colu mn _positi on from dba_ in d_colum ns where table_

16、name=A：TABLE INDEX COLUMN_NAMCOLUMN_POSITIONAIDX AOBJECT ID1索引一定在表上的看性能不用DBA工具，尤其是哪些廉价的工具。看性能一定要看到根上看对象可以使用视图发现数据库存在问题，不要上来就凭经验解决，要先了解数据库的工作过程发现一个DML很慢，1。是否有等待事件2。看索引，访问了哪些表，建立了哪些索引UPDATE索引列要注意页拆分和数据迁移Del对索引有长期影响，需要重建索引Insert会页拆分批量导数据容易导致页拆分通常情况下数据库高度在2-3,如果空数据超过 25%，重建索引会降低一个高度，性能会提高组合索引当某个索引包含有多个列

17、时，我们称这个索引为组合索引。在使用组合索引的时候，要谨慎选择索引列中的列顺序。一般来说，索引的第一列应该是最有可能在where子句中使用的列，并且也是在索引中最具有选择性的列。对于9i以前，查询只能在 where子句中使用索引的第一列时使用索引。SQL select table _n ame,i ndex_ name,colu mn_n ame,colu mn _positi on from dba_ in d_colum ns where table_ name=A：TABLE INDEX COLUMN_NAM COLUMN_POSITIONA IDX_A OBJECT_IDA IND O

18、BJECT IDA A_IND OBJECT_NAM1 E除非在where子句中给object_id指定一个值，否则一般不会使用组合索引。组合索引就是有多个列组合成索弓I,组合索引有前导列的概念，所谓前导列就是指的最先排列的列，比如有 3个列a, b, c, a先排列，然后b在a排列的基础上在排，c同样。 A的选择性低时，b排序才有意义，c同样。索引一旦是杂乱的就失去了意义。使用组合索引一定要包含 a,然后b或c或be。但a的选择性低时，a的作用就不太大了。Where中有ab和c时，特别适合使用组合索引，但使用组合索引不一定就能提高性能。如果A的选择性高，b和c的意义就不太大了列越宽，索引越大

19、，占内存越多。组合索引适合于 A的选择性低的情况，a如果能排序，b和c就是杂乱的，b和c不能单 独做索引组合索引一定是a, b, c同时索引，否则不如建 3个索引从Oracle 9i开始，弓I入了跳跃式索引扫描功能，即使在 where子句中没有指定 empno的数 值，也会可能会使用索引。在10g以后出现了跳跃式扫描,当where中没有出现a,只出现b时，当b的选择性高于a时也会走索引。此时会同时发 生多个扫描，这些扫描是并行的，每个扫描对应着a的一个值。因为a的选择性低Skip scan是oracle自己完成的，sql中没有a的条件在9i前这种情况只能走全表扫描组合索引列名包含在索引中，se

20、lect会走全索引扫描，因为索引小，速度快组合索引可以满足对表的查询，如果有一个空，另一个也非空，也会出现在索引中，但 如果两个都是空就不会出现在索引中跳跃式索引的前提是前导列选择行低，索引跳跃式扫描使用不太多fr?m empjwhsre 占电并 二F arudd 二 123U1TIO1Tselect eirip_najne front emp_wher 二 5 M anl emp_id 二 123:在Oracle数据库的内部，生成了两个查询，然后对两个查询的ROWID进行了联合。当使用跳跃式索引扫描时，自动给 SEX加上了数值，启用了两个查询。如果SEX有50个数值，那么需要启用 50个查询

21、才能完成查询，因此性能大大降低。因此是否适合使用跳跃 式索引扫描，取决于第一个索引列的选择性。一般建议第一个列的可选性非常低。跳跃式索引扫描相对索引直接扫描速度要慢一些，但是相对表扫描速度还是要快很多。使用跳跃式索引的条件1优化器认为是合适的2索引中的前导列的唯一值的数量能满足一定的条件3优化器要知道前导列的值分布(通过分析/统计表得到)4合适的SQL语句跳跃式扫描相对索引扫描慢一些，因为是跳跃式扫描是全索引扫描。不过因为发生在内存中， 所以速度不是很慢统计数据中包括列的数据分布在那个块如果oracle没有选择使用跳跃式索引扫描，那么可能选择使用索引快速全局扫描或全表扫 描。我们花点时间来研究

22、一下 Oracle中扫描数据的方法：1、全表扫描(Full Table Scan FTS)Oracle读取表中所有的行、多块读操作可以大大的减少10的次数、利用多块读可以大大的提高全表扫描的速度、只有在全表扫描的情况下才能使用多块读。在较大的表上不建议使用全表扫描、如果读取表的数据总量超过5% 10%，那么通常进行全表扫描。并行查询可能会使得我们的路径选择采用全表扫描。新技术促使oracle使用全表扫描 db_file_multiblock_read_count是典型的全表扫描设置 索引在表连接问题上有致命问题SQL explain plan for select * from dual;已解

23、释。SQL select * from table(dbms_xpla n. display);PLAN_TABLE_OUTPUTPlan hash value: 272002086| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| Time |0 | SELECT STATEMENT |1 |2 |2(0)| 00:00:01 |1 | TABLE ACCESS FULL | DUAL |1 |2 |2(0)| 00:00:01 |已选择 8 行解释执行语句的执行计划Operation 是执行计划Table access full 全表扫

24、描，上面一行是 sql 语句SQL select rowid from a.a where rownum=1;ROWIDAAAMjjAAEAAADy8AAASQL explain plan for select * from a.a where rowid=AAAMjjAAEAAADy8AAA;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 2574054659| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| TimePLA

25、N_TABLE_OUTPUT| 0 | SELECT STATEMENT | 1 | 93 | 1 (0)| 00:00:01 | 1 | TABLE ACCESS BY USER ROWID | A | 1 | 93 |1 (0)| 00:00:01 |已选择 8 行。Rowid 表示的是一行而不是一列3、索引扫描或者索引查找( index scan index lookup )通过索引找到数据行的 ROWID 、然后通过 ROWID 直接到表中查找数据，这种方式称为索 引查找或者索引扫描。 因为一个 ROWID 对应一个数据行， 因此这种方式采用的也是单块读。在索引中，除了存储每个索引值、

26、还存储相应的 ROWID ，索引扫描分为两步：1、扫描索引得到相应的 ROWID2、通过找到的 ROWID 从表中读取相应的数据每次采用的都是单块 IO 读因为索引小、而且经常使用，因此通常被 cache 到内存中，因此第一步通常是逻辑读(数据 可以从内存中得到)因为表数据比较大、因此第二步读通常是物理读，因此性能较低SQL explain plan for select * from a.a where object_id=1;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 1

27、100842037| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| TimePLAN_TABLE_OUTPUT| 0 | SELECT STATEMENT|1 |93 |2 (0)| 00:00:01 | 1| TABLE ACCESS BY INDEX ROWID| A|1 |93 |2 (0)| 00:00:01 |* 2| INDEX RANGE SCAN| IDX_A |1 |1 (0)| 00:00:01 |PLANTABLE_OUTPUTPredicate Information (identified by operatio

28、n id):2 - access(OBJECT_ID=1) 已选择 14 行。因为访问路径走的是非唯一索引，因此是INDEX RANGE SCAN这个查询中，因为访问的列都在索引中，因此省略了访问的第二步。SQL explain plan for select object_id from a.a where object_id=1;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 810214320| Id | Operation| Name | Rows | Bytes | C

29、ost (%CPU)| Time| 0 | SELECT STATEMENT |1 | 5 |1 (0)| 00:00:01 |1 (0)| 00:00:01 |* 1 | INDEX RANGE SCAN| IDX_A | 1 | 5 |Predicate Information (identified by operation id):PLAN_TABLE_OUTPUT1 - access(OBJECT_ID=1) 已选择 13 行。Where ，=，between 都会走范围索引。 不走索引SQL explain plan for select * from a.a where obje

30、ct_id select * from table(dbms_xplan.display);(0)| 00:00:01 |PLAN_TABLE_OUTPUTPlan hash value: 1100842037| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| TimePLAN_TABLE_OUTPUT0 | SELECT STATEMENT|93 |31 |1 | TABLE ACCESS BY INDEX ROWID| A93 |(0)| 00:00:01 |*2 | INDEX RANGE SCAN| IDX_A |(0)| 00:0

31、0:01 |PLAN_TABLE_OUTPUTPredicate Information (identified by operation id):2 - access(OBJECT_ID create table a.a(a int primary key);表已创建。SQL select index_name from dba_indexes where table_name=A;INDEXSYS_C005162SQL insert into a.a select object_id from dba_objects;已创建 49793 行。SQL commit;提交完成。SQL expl

32、ain plan for select * from a.a where a=2;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 2342676264| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| TimePLAN_TABLE_OUTPUT| 0 | SELECT STATEMENT | | 1 | 13 | 1 (0)| 00:00:01|* 1 | INDEX UNIQUE SCAN| SYS_C005162 | 1

33、| 13 |1 (0)| 00:00:01Predicate Information (identified by operation id):PLAN_TABLE_OUTPUT1 - access(A=2) 已选择 13 行。索引范围扫描1、在唯一键上使用 range 操作符( 、 =、 explain plan for select * from a.a where a select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 2932832188| Id | Operation | Name | R

34、ows | Bytes | Cost (%CPU)| Time |0 | SELECT STATEMENT | |1 |13 |1 (0)| 00:00:01 |*1 | INDEX RANGE SCAN|SYS_C005162 | 1 | 13 |1 (0)| 00:00:01 |Predicate Information (identified by operation id):PLAN_TABLE_OUTPUT1 - access(A create table a.a (a1 int,a2 int,a3 int,a4 int);表已创建。SQL create index idx_a on

35、 a.a(a1,a2,a3);索引已创建。SQL expla in pla n for select * from a.a where a 1 =2;已解释。SQL select * from table(dbms_xpla n. display);PLAN_TABLE_OUTPUTPlan hash value: 1100842037| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| TimeIPLAN_TABLE_OUTPUT|0 I SELECT STATEMENTII1 I52 I2(0)I 00:00:01 I|1 | TABLE

36、 ACCESS BY INDEX R0WID| A|1 I52 I2(0)I 00:00:01 I|*2 | INDEX RANGE SCANI idx_a |1 II1(0)I 00:00:01 IPLAN_TABLE_OUTPUTPredicate Information (identified by operation id):2 - access(A1=2)Note-dynamic sampling used for this statement已选择18行。部分列：abc三个索引中，只使用了ab或ac只要是非唯一索引，一定是有范围的索引全扫描查询出的数据必须全部从索引中得到SQL c

37、reate table a (a int primary key);表已创建。SQL expla in pla n for select a from a where a1;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 2248738933| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 0 | SELECT STATEMENT | 47334 | 600K| 24 (9)| 00:00:01 |* 1 |

38、 TABLE ACCESS FULL| A | 47334 | 600K| 24 (9)| 00:00:01 |Predicate Information (identified by operation id):PLAN_TABLE_OUTPUT1 - filter(A1)Note- dynamic sampling used for this statement 已选择 17 行。索引快速扫描 扫描索引块中的所有数据块，这点与full index scan 相似，但是索引快速扫描不进行数据的排序，在这种方式下， 可以使用多块读功能、 也可以使用并行读功能， 最大化数据的吞吐量。 SQL s

39、elect table_name,index_name,column_name from dba_ind_columns where table_n ame=A;TABLE INDEXCOLUMN_NAMA IDX_AOBJECT_IDSQL explain plan for select object_id from a where object_id !=0;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 1047246182| Id | Operation| Name |

40、Rows | Bytes | Cost (%CPU)| Time | 0 | SELECT STATEMENT| 47847 | 607K| 34 (6)| 00:00:01 |I* 1 | INDEX FAST FULL SCAN | IDX_A | 47847 |607K|34(6)| 00:00:01 |Predicate In formatio n (ide ntified by operati on id):PLAN_TABLE_OUTPUT1 - filter(OBJECT_ID0)Note-dyn amic sampli ng used for this stateme nt已选

41、择17行读索引都是顺序的索引全扫描是按照链接顺序扫描索引 快速扫描是同时读多个块索引全扫描查询出的数据必须全部从索引中得到使用索引全扫描的条件是索引列设定了非空，并且查找结果排序如果索引列未设置非空，则执行全表扫描如果查找结果不要求排序，则走索引快速扫描SQL desc a;名称是否为空？类型OWNEROBJECT_NAMESUBOBJECT_NAMEOBJECT_IDDATA_OBJECT_IDVARCHAR2(30)VARCHAR2(128)VARCHAR2(30)NOT NULL NUMBERNUMBERSQL expla in pla n for select object_id fr

42、om a order by object_id;已解释。SQL select * from table(dbms_xpla n. display);PLAN_TABLE_OUTPUTPlan hash value: 257628703| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| Time | 0 | SELECT STATEMENT | | 1371K| 16M| 4424 (1)| 00:00:54 | | 1 | INDEX FULL SCAN | IDX_A | 1371K| 16M| 4424 (1)| 00:00:54 |N

43、otePLAN_TABLE_OUTPUT- dynamic sampling used for this statement 已选择 12 行。SQL explain plan for select object_id from a ; 已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 1047246182| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 1

44、371K| 16M| 1203 (1)| 00:00:15 | | 1 | INDEX FAST FULL SCAN | IDX_A | 1371K| 16M| 1203 (1)| 00:00:15 |NotePLAN_TABLE_OUTPUT- dynamic sampling used for this statement 已选择 12 行。大家说 select count(*) 走什么类型的索引 SQL explain plan for select count(*) f rom a;已解释。SQL select * from table(dbms_xplan.display);PLAN

45、_TABLE_OUTPUTPlan hash value: 484915617| Id | Operation| Name | Rows | Cost (%CPU)| Time| 0 | SELECT STATEMENT|1 | 1203 (1)| 00:00:15 | 1 | SORT AGGREGATE | 2 | INDEX FAST FULL SCAN | IDX_A | 1371K| 1203 (1)| 00:00:15 |NotePLAN_TABLE_OUTPUT- dynamic sampling used for this statement已选择 13 行如果 select

46、count( 非索引列 ) 呢？SQL explain plan for select count(owner) from a;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 3918351354| Id | Operation| Name | Rows | Bytes | Cost (%CPU)| Time|0 | SELECT STATEMENT| |1 |17 |5967(2)| 00:01:12 |1 |SORT AGGREGATE| |1 |17 | |2 |TABLE

47、 ACCESS FULL | A| 1371K|22M|5967 (2)| 00:01:12 |NotePLAN_TABLE_OUTPUT- dynamic sampling used for this statement 已选择 13 行。Where 条件中使用了 !=或者 他的索引如何走？ 分两种情况SQL explain plan for select object_id from a where object_id 10;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 1

48、047246182| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 1370K| 16M| 1204 (1)| 00:00:15 | |* 1 | INDEX FAST FULL SCAN | IDX_A | 1370K| 16M| 1204 (1)| 00:00:15 |Predicate Information (identified by operation id):PLAN_TABLE_OUTPUT1 - filter(OBJECT_ID10)Note- dyn

49、amic sampling used for this statement 已选择 17 行。如果 select 条件中只包含了索引列，则走索引快速扫描SQL explain plan for select * from a where object_id 10;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 2248738933| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT ST

50、ATEMENT | | 1370K| 231M| 6035 (3)| 00:01:13 | |* 1 | TABLE ACCESS FULL | A | 1370K| 231M| 6035 (3)| 00:01:13 |Predicate Information (identified by operation id):1 - filter(OBJECT_ID10)PLAN_TABLE_OUTPUTNote- dynamic sampling used for this statement已选择 17 行。如果 select 中包括了全部列，则走全表扫描那么如果是 或 explain plan

51、 for select object_id from a where object_id 10;已解释。SQL select * from table(dbms_xplan.display);PLAN_TABLE_OUTPUTPlan hash value: 1047246182| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 1368K| 16M| 1204 (1)| 00:00:15 | |* 1 | INDEX FAST FULL SCAN| IDX_A | 13

52、68K| 16M| 1204 (1)| 00:00:15 |Predicate Information (identified by operation id):PLAN_TABLE_OUTPUT1 - filter(OBJECT_ID10) note- dynamic sampling used for this statement 已选择 17 行。如果 select 列里有索引列，则走索引快速扫描SQL explain plan for select * from a where object_id 10;已解释。SQL select * from table(dbms_xplan.display);Plan hash value: 1100842037| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| TimePLAN_TABLE_OUTPUT| 0 | SELECT STATEMENT| | 1368K| 230M| 5127 (1)| 00: